当点击事件落在重叠视图上，UIKit响应者链的判定规则直接决定该谁处理，认真捋清hitTest与point方法的调用顺序，才能解决按钮失灵的疑难杂症。

当点击一个看似“应该响应”的按钮却毫无反应时，界面就像突然被施了沉默咒。明明按钮就在那儿，视觉效果完好，可手指戳下去就是没动静。这种情况十有八九是事件在层层视图之间“迷路”了，而负责给事件指路的，就是UIKit响应者链里的两个关键方法：hitTest(_:with:)和point(inside:with:)。把它们调用顺序搞明白，那些奇怪的“按钮失灵”问题基本就能手到擒来。

一、从一次按钮失灵说起

前些天遇到一个特别典型的场景：一个弹窗上面盖了一个近乎透明的装饰视图，弹窗里有个关闭按钮。在真机上一按，按钮高亮了一下就立刻消失，有时候干脆连高亮都没有，就像点了空气。我撕掉那个装饰视图，按钮立刻恢复正常。问题很明确：事件被装饰视图“截胡”了，压根没传到按钮上。

这种问题初看毫无头绪，因为装饰视图既没有添加点击手势，也没有重写任何触摸方法。那为什么它能把事件“抢”走？要解答这个疑惑，就必须看UIKit在触摸发生时内部到底做了什么。

二、先聊聊响应者链是什么

在iOS世界里，屏幕上的每一个可交互控件都是“响应者”。一条响应者链可以理解为“遇到事情找谁解决”的传递顺序：当某个视图处理不了事件，它就会把事件丢给下一个“上级”。这个上级通常是它的父视图，再往上就是视图控制器、窗口、应用和AppDelegate，一直追到没人处理为止。

举个例子，一个按钮的响应者链大概是这样的：

按钮 → 按钮的父视图 → 视图控制器 → 窗口 → 应用 → AppDelegate

响应者链的伟大之处在于，它给事件处理提供了一条“逐级上报”的通道。比如一个UITapGestureRecognizer加在父视图上，子按钮也能触发它，就是因为点击事件会沿着链路上溯。理解了这条链，接下来最关键的问题就是：事件最开始应该交给链上的哪个节点？这个选择过程，就是命中的测试。

三、点击事件是怎么找“人”的：hitTest与point

3.1 认识这两个方法

UIKit在每次触摸屏幕时，会先做一次“点名”，找出触摸点到底落在哪个视图身上。这个点名过程依赖两个核心方法：

• point(inside:with:)：判断传入的点是否在当前视图的坐标范围内。它返回一个布尔值，相当于“这个点属不属于我”。
• hitTest(_:with:)：真正找出“谁是最终被点中的视图”。它会从视图树的顶层往下遍历，返回一个具体的UIView。

可以这样想：point是“试探”，hitTest是“裁定”。两者经常一起出现，但职责完全不同。

3.2 调用顺序：先hitTest后point，还是反过来？

网上有些解释会把人绕晕，其实真正的顺序非常清晰：

系统先调用根视图（通常是UIWindow）的hitTest，然后hitTest内部会遍历当前视图的所有子视图。对于每个子视图，先调用子视图的hitTest（递归），再在递归子视图的过程中调用子视图自身的point(inside:with:)来判断触摸点是否落在子视图范围内。

更准确地说，point(inside:with:)是hitTest内部调用的一个“关卡”。默认的hitTest实现逻辑大概是：

// 技术栈：Swift / UIKit
override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
    // 1. 如果视图隐藏、不可交互或者透明度极低，直接返回nil
    if self.isHidden || !self.isUserInteractionEnabled || self.alpha < 0.01 {
        return nil
    }
    
    // 2. 如果触摸点不在当前视图范围内，直接返回nil
    if !self.point(inside: point, with: event) {
        return nil
    }
    
    // 3. 从后往前遍历子视图（注意顺序，后添加的在上面）
    for subview in self.subviews.reversed() {
        // 把当前的触摸点转换成子视图的坐标系
        let convertedPoint = self.convert(point, to: subview)
        
        // 递归调用子视图的hitTest
        if let hitView = subview.hitTest(convertedPoint, with: event) {
            return hitView  // 找到了最顶层的响应视图
        }
    }
    
    // 4. 如果子视图都不满足，那就自己来
    return self
}

可以看到，point(inside:with:)在第二步被调用，它的结果直接决定了当前视图是否会“放弃”继续向下查找。如果point返回false，当前视图会立刻返回nil，它及其所有子视图都不会再参与事件命中。

3.3 通过示例看完整过程

假设有两个视图A和B，B被添加在A之上，并且B比A大一圈。点击B区域内但没有和A重叠的部分时：

1. 系统调用UIWindow的hitTest，窗口内部先普及到根视图。
2. 根视图调用子视图A的hitTest。
3. A先检查自己的point(inside:with:)。如果点击点在A范围内，继续往下。
4. A发现自己有子视图B，于是把点转换到B坐标系，调用B的hitTest。
5. B的point返回true，并且B没有子视图，于是B告诉自己“我就是最终响应者”。
6. 返回B，后续事件全部发给B。

整个过程可以理解为一次“从上往下、从外到内”的筛选。每一次递归其实都在签证：这个点是不是我的孩子？如果是，再问孩子里面谁愿意接收。

四、实战：解决一个重叠视图导致按钮失灵的bug

4.1 问题描述与代码

现在回到开头那个弹窗场景。我简化一下结构：

• 容器视图（containerView）承载整个弹窗。
• 弹窗上有个关闭按钮（closeButton）。
• 弹窗上面叠了一个透明的装饰视图（overlayView），它其实是一个带模糊效果的背景层，但可能因为布局写得太随意，把它加在了按钮的上层。

代码如下：

// 技术栈：Swift / UIKit
import UIKit

class ExampleViewController: UIViewController {
    private let containerView = UIView()
    private let closeButton = UIButton(type: .system)
    private let overlayView = UIView()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        setupViews()
    }
    
    private func setupViews() {
        // 容器：负责承载所有内容
        containerView.frame = CGRect(x: 40, y: 200, width: 300, height: 200)
        containerView.backgroundColor = .white
        view.addSubview(containerView)
        
        // 关闭按钮：放在容器右下角
        closeButton.frame = CGRect(x: 240, y: 140, width: 40, height: 40)
        closeButton.setTitle("✕", for: .normal)
        closeButton.addTarget(self, action: #selector(closeTapped), for: .touchUpInside)
        containerView.addSubview(closeButton)
        
        // 装饰视图：覆盖整个容器，注意它是后添加的，所以层级在按钮之上
        overlayView.frame = containerView.bounds
        overlayView.backgroundColor = UIColor.black.withAlphaComponent(0.1)
        containerView.addSubview(overlayView)
    }
    
    @objc private func closeTapped() {
        print("关闭按钮点击成功")
    }
}

运行一下就知道，点击关闭按钮时“关闭按钮点击成功”永远不会打印，因为触摸被overlayView吞掉了。

4.2 错误分析与排查

第一步，确认按钮的isUserInteractionEnabled为true，isHidden为false，排除最简单的可能性。

第二步，查看视图层级。这里因为有代码，能明确看到overlayView被添加在按钮之后，位于按钮上方。使用hitTest的逻辑推演：系统从容器开始，遍历子视图，子视图顺序是从后往前。容器内部先有按钮，后有覆盖层，所以遍历时先检查覆盖层。覆盖层的point(inside:with:)对点击点返回true，同时覆盖层没有子视图，于是覆盖层自己成为命中视图。按钮根本没有机会被检查。

这种问题在以前常被描述为“按钮被遮挡”，但严格说，是“命中测试被遮挡”。因为即使覆盖层是透明的，它依然可以成为命中视图。只要它是userInteractionEnabled的（默认就是），它就会无情地截走事件。

4.3 修复方案

办法很多，最直接的是调整层级，把按钮移到覆盖层之上：

// 技术栈：Swift / UIKit
// 调整添加顺序，确保按钮最后添加，这样按钮就在最高层级
containerView.addSubview(overlayView)
containerView.addSubview(closeButton)

但有时候你不能随便调整层级，例如覆盖层默认就必须在最上面。这时候可以重写overlayView的hitTest，让它“把机会让给下面的兄弟视图”。希望让覆盖层透明区域不拦截事件，但又不影响它上面的其他控件？可以把覆盖层的isUserInteractionEnabled设为false，但这样覆盖层上的所有子控件也会失效。更精细的做法是重写point(inside:with:)，让它在某些点返回false。

比如，如果我只希望覆盖层响应边缘区域的点击，而把按钮所在区域让给按钮，可以这样：

// 技术栈：Swift / UIKit
class PassThroughOverlayView: UIView {
    /// 记录按钮所在的区域，用于排除
    var excludedRect: CGRect = .zero
    
    // 重写point方法，如果点击点落在排除区域，就返回false
    override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
        // 特别注意：这里使用的是覆盖层自身的坐标系
        if excludedRect.contains(point) {
            // 让按钮区域“漏过去”
            return false
        }
        // 其他区域照常响应
        return super.point(inside: point, with: event)
    }
}

然后在设置布局时，把按钮的frame赋值给excludedRect：

// 技术栈：Swift / UIKit
let passOverlay = PassThroughOverlayView(frame: containerView.bounds)
passOverlay.excludedRect = closeButton.frame  // 注意转换坐标系
passOverlay.backgroundColor = UIColor.black.withAlphaComponent(0.1)
containerView.addSubview(passOverlay)

这里有一个坑：closeButton.frame是相对于containerView的，而passOverlay也是containerView的子视图，且它们坐标系一致，所以可以直接赋值。如果层级更深，需要用convert转换坐标。

上面的做法是重写point，其实重写hitTest更灵活。比如希望覆盖层忽略所有触摸，但保留其子视图的响应，可以这样：

// 技术栈：Swift / UIKit
override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
    // 先调用父类逻辑，得到原本的命中视图
    let hitView = super.hitTest(point, with: event)
    
    // 如果命中视图不是self而是某个子视图，那就返回这个子视图
    if hitView != self {
        return hitView
    }
    
    // 如果命中视图就是self，说明没有子视图接收，此时返回nil，让下层视图接收
    return nil
}

这个方案让覆盖层变成“透明的空气”，但覆盖层上的子按钮还能正常点击。很多自定义弹窗就是靠这个思路解决“透明遮罩遮住后面点击”的问题。

五、关联技术：UIView的交互开关

在实际开发中，有几个属性经常跟命中测试搅在一起，很多人分不清，这里一并说清楚。

• isUserInteractionEnabled：控制当前视图是否参与事件响应。设为false后，该视图及其子视图都会忽略触摸事件。父视图关闭，子视图也会跟着失去响应，这一点非常重要。
• isHidden：隐藏视图直接跳过命中测试，不管它原来多能接收事件。
• alpha：当透明度小于等于0.01时，视图会直接不参与命中测试。注意，不是0.0，而是0.01，有极小的特殊情况。

它们的共同点是都在系统的hitTest内部被检查，只要有一项不满足，当前视图就会提前返回nil。所以当遇到按钮失灵，优先检查这三兄弟。

六、应用场景与技术优缺点

这种“定制命中测试”的技术在真实项目中应用很广。

• 弹窗遮罩：底部弹窗经常需要点击遮罩层关闭，但遮罩上放的按钮又要能响应。通过重写hitTest来区分“点击空白处关闭”和“点击按钮不关闭”。
• 不规则控件：比如一个圆形按钮，但实际frame是正方形，希望点击圆外不响应。这时候重写point(inside:with:)，把点与圆心的距离跟半径做比较，超过半径就返回false。
• 半透明装饰层：请参照前面的PassThroughOverlayView。

这些技术的优势是很直接、精准，能解决系统默认行为无法覆盖的场景。缺点也明显：如果你过度使用，代码会变得难以维护，尤其当你重写了hitTest却不注意坐标系转换，会产生很多奇怪的递归问题。而且，每多一次hitTest重写，事件查找路径就会多一点神秘感，团队其他人接手时很容易懵。

七、注意事项

这里有几个特别容易翻车的地方，值得拿出来单独讲。

第一，坐标转换千万别搞错。hitTest里面的点永远是以“当前视图自身坐标系”为参照的。当你遍历子视图时，必须用convert(_:to:)把点转换到子视图坐标系，否则判断会彻底错乱。

第二，不要轻易在hitTest里做耗时操作。因为一次触摸可能会递归调用很多次，尤其视图层级复杂时，性能可能会崩。如果你在里面写循环或者网络请求，那用户触摸屏幕的每一刻都会卡顿。

第三，谨慎处理alpha。如果你把alpha设成0.01以下，视图会直接失去响应，有些同学为了视觉上隐藏一个视图会设成0.0，然后发现它的子按钮全“死了”还找不到原因。这时候要记住，真正的隐藏应该用isHidden，或者用removeFromSuperview。

第四，重写point(inside:with:)时，不要忘了也要考虑子视图。因为这个方法只管当前视图的范围，如果当前视图返回false，那么它的所有子视图都不会被检查到。所以如果你想让某个子视图在超出父视图边界时还能被点击，就得父视图在point中扩大判断范围，或者在hitTest中做特殊处理。

八、文章总结

按钮失灵的谜底，其实就藏在hitTest和point这对黄金搭档的调用顺序里。系统先触发hitTest，hitTest再内部调用point来筛掉范围外的视图。只要把这一层逻辑理顺，很多重叠视图的点击问题都能迎刃而解。以后遇到类似情况，先别急着砸键盘，冷静下来看一眼视图层级，再想想这两个方法，说不定下一秒问题就消失了。遇到真正复杂的需求，不要怕，重写hitTest或point就是你的终极武器，不过要记住，武器虽好，别耍过头就是。