opacity: 0 不影响事件响应，点击失效主因是 z-index 层叠遮挡或缺少 pointer-events: none；需检查层叠上下文、定位与尺寸，而非归咎透明度。
opacity: 0 后点击失效？不是透明的问题，是事件没被屏蔽
元素设了 opacity: 0 却点不了下层内容，说明它仍在拦截事件——因为 opacity 只改视觉透明度，不改变事件响应能力。浏览器照常把它当作可点击目标，哪怕你看不见它。
要让元素“透明但可点”，根本不需要额外操作：默认就是如此。只要没加 pointer-events: none，opacity: 0 的元素依然能接收 click、hover、focus 等所有指针事件。
- 常见误操作：一边写
opacity: 0，一边又加pointer-events: none，结果既看不见也点不到 - 想保留 hover 效果？直接写
opacity: 0; transition: opacity 0.2s;，鼠标移入时再用 JS 或 :hover 切回opacity: 1 - 注意：opacity 会继承并影响子元素，如果只想背景透明而文字不透明，优先用
background-color: rgba(0,0,0,0.5)而非全局 opacity
为什么加了 opacity: 0 还挡着下面的按钮？
这不是 opacity 的问题，而是层叠顺序（z-index）和定位在起作用。opacity 为 0 的元素依然占据文档流、参与层叠计算，只要它的 z-index 比下层高，就物理上盖在上面，自然拦截点击。
验证方法：打开开发者工具，选中该元素，在 “Computed” 面板里确认它的 z-index 是具体数值（不是 auto），且父级没有意外创建新层叠上下文（比如带 transform、filter 或 opacity 的祖先）。
立即学习“前端免费学习笔记（深入）”；
- 修复方式一：降低它的
z-index，或给下层元素设更高z-index（前提是两者同属一个层叠上下文） - 修复方式二：移除它的
position（如absolute），让它回归文档流自然排序 - 修复方式三：如果它本就不该参与交互，直接加
pointer-events: none，而不是调 opacity
想透明 + 可点 + 不干扰布局，用 visibility: hidden 行不行？
不行。visibility: hidden 会让元素保留在文档流中、占位，但**仍然响应鼠标事件**——这点和很多人直觉相反。它只是“看不见”，不是“不存在于事件流”。所以它照样会拦截点击，而且比 opacity: 0 更难调试，因为开发者工具里看不出它是否在响应事件。
真正安全的组合只有两个：
-
opacity: 0; pointer-events: auto;→ 透明、可见（对屏幕阅读器）、可点、可 hover、占位 -
visibility: hidden; pointer-events: none;→ 不可见、占位、不可点、不可 hover（但键盘焦点仍可能进入，需额外处理tabindex="-1"）
别混用 visibility: hidden 和 pointer-events: auto，这是典型的“以为隐藏了，其实还在挡路”陷阱。
移动端点击无响应？别只盯着 opacity
在 iOS Safari 或部分安卓 WebView 中，opacity: 0 元素有时点击无效，往往不是 opacity 导致的，而是缺少触发点击区域的 CSS 声明。
- 给该元素加
cursor: pointer（桌面端）或确保它有明确宽高（移动端更关键） - 检查是否被
touch-action: none或父级overflow: hidden截断了触摸事件路径 - 避免用
display: inline+opacity: 0，某些旧内核下 inline 元素透明后事件区域会异常收缩；改用display: inline-block或block
opacity 本身在所有现代浏览器中对事件无副作用，出问题时，90% 是层叠、尺寸、或平台特定的点击区域判定逻辑在作怪。
