position: absolute 易引发点击劫持，因其脱离文档流且z-index受层叠上下文限制；若父容器未显式设z-index或意外创建新上下文，恶意覆盖层可遮挡真实按钮导致误触。
position: absolute 为什么容易引发点击劫持
因为 position: absolute 元素脱离文档流，z-index 控制层叠顺序，但若未显式设置 z-index 或父容器未形成新的层叠上下文，实际渲染层级可能与预期严重不符——攻击者可把恶意按钮盖在真实按钮上方，用户“点着了却没点上”。
- 常见错误现象：
click事件触发了隐藏的覆盖层，而用户以为自己在操作主界面（比如支付按钮被透明div覆盖） - 典型使用场景：弹窗、下拉菜单、广告悬浮窗、表单内嵌提示气泡
- 关键风险点：父容器用了
position: relative但没设z-index，子元素position: absolute的 z-index 值再大也只在该局部上下文中生效 - 兼容性影响：IE8+ 支持
z-index，但若祖先元素有opacity 、<code>transform、filter等，会隐式创建层叠上下文，打乱预期层级
如何用 CSS 审计定位元素的层叠安全性
不能只看代码里写了什么 z-index，得验证它是否真的在起作用。核心是检查“层叠上下文链”是否可控。
- 用浏览器开发者工具的 Layers 面板（Chrome DevTools → More Tools → Layers）查看每个
position: absolute元素所属的层叠上下文 ID，确认它是否被意外截断 - 检查所有祖先元素是否无意中创建了新层叠上下文：
opacity: 0.99、transform: translateZ(0)、will-change: transform都会触发，哪怕值看起来“没变化” - 对关键交互区域（如按钮、输入框、提交区），强制设置
z-index: 2147483647并加!important—— 不是为了滥用，而是作为审计基线：如果此时仍被遮挡，说明问题出在层叠上下文隔离，而非数值不够
防点击劫持的最小安全实践组合
不是禁用 position，而是让定位行为可预测、可收敛、可验证。
- 所有含
position: absolute或position: fixed的组件，父容器必须显式声明position: relative+z-index: 0（或更高），以锚定其层叠范围 - 禁止在业务关键区域（如
.submit-btn、#pay-form）使用pointer-events: none或visibility: hidden临时隐藏元素——这会让覆盖层有机可乘；改用display: none或彻底移除 DOM - 对第三方 SDK 插入的浮动元素（如客服浮窗、统计 tracker），用
iframe隔离，或通过CSS containment: layout paint限制其渲染影响范围（注意 Safari 支持较晚） - 上线前跑一次简单检查脚本：
document.querySelectorAll('[style*="position: absolute"], [style*="position: fixed"]').forEach(el => { console.log(el, window.getComputedStyle(el).zIndex) })
移动端 touch 事件下的特殊陷阱
touchstart 和 click 在 iOS 上有 300ms 延迟机制，而某些定位覆盖层恰好利用这个时间差完成注入——更隐蔽，也更难复现。
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
z-index数值大小来“压过”第三方广告 SDK 的浮层；它们常动态插入body底层，且用!important锁死样式 - 对
touch-action: manipulation的使用要谨慎：它虽能关闭延迟，但若目标元素被绝对定位覆盖，用户仍会误触底层 - 真机测试时重点观察“快速连点”场景：第一次点可能触发覆盖层，第二次点才落到目标上——这种非确定性行为正是点击劫持的典型特征
z-index，而是意识到：只要一个 position: relative 父容器漏了 z-index，整个子树的定位安全性就归零。 
