UIView超出父视图边界时子控件点击事件被底层拦截如何解决

• 自定义实现了一个作为提示浮层（tooltip box）的UIView，通过锚点约束添加为键盘附属视图（keyboard accessory view）的子视图，布局在父视图边界之外，悬浮在与它无直接层级归属关系的UITextView上方
• 浮层上添加的UIButton、UISegmentedControl无法正常响应点击，触摸事件直接被底层的UITextView拦截

错误猜想排除 #

最初怀疑是第一响应者冲突导致事件被拦截：由于UITextView处于第一响应者状态才弹出键盘及键盘附属视图，若强制将提示浮层设为第一响应者，会触发两个严重问题：

• UITextView失去第一响应者状态后键盘会直接收起
• UITextView失去第一响应者时自身约束会更新，视图整体向下滑动，连带其他视图位置偏移，交互体验极差
  因此该方案完全不可行。

根因确认 #

通过查阅官方文档+重写hitTest(_:with:)打日志测试，最终定位到问题根源是iOS系统的命中测试规则：

如果触摸位置在某个视图的bounds范围外，hitTest(_:with:)方法会忽略该视图及其所有子视图。因此即便视图的clipsToBounds属性为false，位于视图边界外的子视图即使刚好包含触摸点，也不会被命中测试逻辑返回。

测试观测到的现象完全符合该规则：

• 提示浮层整体位于键盘附属视图边界外时，浮层上的控件完全无点击响应，浮层自身重写的hitTest(_:with:)方法根本不会被调用
• 调整约束让浮层部分进入键盘附属视图bounds范围内时，和父视图bounds重叠区域的控件可以正常响应点击、触发hitTest(_:with:)调用，仍在父视图边界外的区域控件依旧无法接收事件，触摸直接透传给底层UITextView

首先明确：给浮层上的控件添加冗余点击手势的方案不可行——手势识别的命中判定逻辑和UIView默认事件传递遵循完全相同的规则，只要控件所在视图在父视图bounds外，绑定的手势根本不会被系统识别触发。
可行方案按推荐优先级排序如下：

方案1：重写浮层父视图的hitTest(_:with:)（最优方案，改动最小） #

仅需在浮层的直接父视图（即键盘附属视图）中重写命中测试方法，扩大命中判定范围，将浮层区域纳入事件接收范围即可，不需要调整现有布局、不需要改动第一响应者状态。
示例代码：

override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
    // 提前将触摸点转换到浮层坐标系下判断
    let convertedPoint = convert(point, to: tooltipView)
    if tooltipView.point(inside: convertedPoint, with: event) {
        // 触摸点落在浮层范围内时，将事件交给浮层做后续内部命中判定
        return tooltipView.hitTest(convertedPoint, with: event)
    }
    // 非浮层区域走系统默认命中逻辑
    return super.hitTest(point, with: event)
}

该方案的优势：

• 不改变原有视图层级和约束布局
• 不影响第一响应者状态，不会触发键盘收起、布局移位问题
• 仅在触摸点落在浮层上时接管事件，其余场景完全不影响原有事件传递逻辑

方案2：调整浮层的视图层级（最符合系统设计规范） #

如果不想自定义命中测试逻辑，可以将提示浮层直接添加到和键盘附属视图、UITextView同层级的顶层父视图（或直接添加到当前UIWindow）上，保证浮层自身完全在其父视图的bounds范围内，再通过坐标转换计算浮层的目标位置即可。
该方案完全适配系统默认的命中测试规则，不需要做任何事件传递的自定义修改，但需要手动管理浮层的生命周期：比如键盘收起、UITextView退出编辑状态时，要同步隐藏或移除浮层，避免出现视图残留。

• 不要强制切换浮层为第一响应者：会导致键盘收起、布局错位，体验不可用
• 不要依赖clipsToBounds = false实现交互：该属性仅控制子视图超出部分的显示效果，完全不影响命中测试逻辑
• 不要单独给浮层控件添加点击手势：手势识别同样受命中测试规则限制，无法解决超出父视图bounds的事件拦截问题

内容的提问来源于stack exchange，提问作者clearlight