pointer-events: none 是最直接的穿透解法，它使上层遮挡层不响应鼠标/触控事件，让点击透传到底层可交互元素，且不影响布局、动画与视觉呈现。
pointer-events: none 是最直接的穿透解法
遮挡层点不了，不是底层元素“坏了”，而是上层元素在吃点击——pointer-events: none 就是告诉浏览器：“别管我，让事件往下走”。它不改布局、不触发重排、不影响动画或焦点，只关鼠标/触控事件。视觉照常显示，点击却能落到下面的 <a> 或 <button> 上。
- 必须确认遮挡层纯属装饰（比如半透明蒙版、背景光效），不需要任何交互
- 该属性可继承：如果遮挡层里有关闭按钮等子元素，得单独给它加
pointer-events: auto - 普通 HTML 元素只认
auto和none；写visible或fill会被忽略 - 伪元素（
::before/::after）默认参与事件流，哪怕只是画个阴影，也得显式设pointer-events: none
为什么 z-index 常常调了也没用
z-index 不是全局排序器，它只在同一个层叠上下文内有效。一个 transform: translateY(0)、opacity: 0.99 或 filter: blur(1px) 就会让整棵子树脱离父级上下文，导致你设的 z-index 根本没地方比。
- 打开开发者工具 → “Computed” 面板，搜
stacking context，找到第一个标有 “This element establishes a stacking context” 的祖先——它大概率就是让z-index失效的源头 - 临时给可疑父级加
outline: 2px solid red，看是否真覆盖目标热区 - 别依赖
opacity: 0或visibility: hidden：它们依然拦截点击；只有display: none或pointer-events: none才真正释放事件流
移动端和嵌套层级里的特殊坑
在 iOS Safari 上，pointer-events: none 对 touchstart/touchend 生效，但旧版 Safari（none 层下的 <input>，可能连软键盘都不弹。更麻烦的是，多个 pointer-events: none 层叠时，事件穿透顺序不是按 DOM 顺序，而是严格按渲染树绘制顺序。
- 真机测试必做：在 iOS 上点被设为
none的区域，确认下层<button>是否真能响应click - 避免父层
none+ 子层auto的嵌套写法，部分安卓 WebView 仍有穿透失败案例；改用绝对定位 +z-index分离图层更稳 - 若需条件性穿透（比如点击空白处关闭弹窗），就得靠 JS 控制：
overlay.style.pointerEvents = 'auto'/'none'
排查谁在真正挡路
不是所有“点不了”都该加 pointer-events。先得确认谁真在盖着链接——开发者工具里右键目标区域，“检查”跳到的 DOM 节点往往就是罪魁祸首。
立即学习“前端免费学习笔记（深入）”；
- 重点排查空
<div>、<section>或设置了width/height但没内容的容器，它们常被忽略却稳稳盖着链接 - “Computed” 面板里搜
pointer-events，看值是不是none（哪怕带删除线，也说明被祖先设过） - 用浏览器“Rendering”面板勾选 “Paint flashing”，能直观验证事件接收链是否连通
pointer-events: none 层叠时，穿透行为在桌面和真机上可能不一致，尤其 iOS Safari；别只在 Chrome 里点两下就认为 OK 了。 
