pointer-events: none 是解决遮挡层拦截事件的最直接方法，它使元素不捕获任何鼠标/触控事件，事件透传至下一层可交互元素；需注意伪元素默认参与事件流、子元素需显式设 auto、多层穿透依赖渲染顺序、真机测试必要。
pointer-events: none 是最直接的解法
给遮挡层加 pointer-events: none，它就不再捕获任何鼠标事件（click、mousemove、mouseenter 等），事件会透传到视觉上紧邻的下一层可交互元素。这个属性不改布局、不触发重排、不影响动画或透明度，只关鼠标/触控。
常见错误是以为设了 z-index 就能解决——其实 z-index 只控制绘制顺序，不决定事件归属；真正“吃点击”的是上层元素本身，默认就是 pointer-events: auto。
- 必须确认遮挡层纯属视觉装饰（比如半透明蒙版、光效、自定义光标容器）
- 伪元素（
::before/::after）默认参与事件流，哪怕只是画个阴影，也得显式加pointer-events: none - 不要写
-webkit-pointer-events等前缀，现代浏览器已全支持标准属性
子元素需要交互时怎么处理
如果遮罩层里有关闭按钮、拖动手柄等子元素，它们不能跟着父层一起失活。此时要单独给子元素设 pointer-events: auto：
.overlay {
pointer-events: none;
}
.overlay .close-btn {
pointer-events: auto;
}
注意：pointer-events 不继承，子元素设 auto 才能恢复响应；但别在父层设 none 后又指望子层“自动穿透回来”——这是无效的。
立即学习“前端免费学习笔记（深入）”；
- 若子元素是伪元素（如
button::before），它无法独立设pointer-events，得用真实 DOM 元素包裹 - 多个
pointer-events: none层叠时，事件穿透顺序取决于渲染树绘制顺序，不是 DOM 顺序 - 部分安卓 WebView 对嵌套
none+auto支持不稳定，真机测试必做
移动端和真机测试容易忽略的坑
iOS Safari 上，pointer-events: none 对 touchstart/touchend 生效，但旧版 Safari 可能导致 none 层下的 <input> 无法唤起软键盘；Android 部分 WebView 在 iframe 内穿透失败。
- 务必在真机上点被设为
none的区域，确认下层<button>是否真能触发click - 避免用
opacity: 0或visibility: hidden替代 —— 它们依然拦截点击 - 若需条件性穿透（如点击空白处关闭弹窗），用 JS 动态切换：
overlay.style.pointerEvents = 'auto'/'none'
为什么有时候加了 pointer-events: none 还没用
事件穿透只发生在视觉堆叠顺序下的“紧邻下一层”，不是跳过所有层直达最底层。如果遮罩层和目标元素之间还隔着一个未设 pointer-events: none 的父容器，事件就会在那里被卡住。
排查步骤：
- 打开开发者工具 → “Computed” 面板，搜
stacking context，找到第一个标有 “This element establishes a stacking context” 的祖先 —— 它大概率就是让z-index失效、也让事件路径变复杂的源头 - 右键目标热区，“检查”跳转到的 DOM 节点，往往就是实际挡路的那个空
<div>或未设样式的容器 - 临时给可疑父级加
outline: 2px solid red，看是否真覆盖了你要点击的区域
真正关键的不是“有没有加 pointer-events: none”，而是从目标元素往上数，中间所有层是否都放行了事件。
