视频或Canvas元素因浏览器特殊渲染机制穿透遮罩层，根本原因是原生控件运行在UI层高于CSS层，解法包括移除controls、自建控件、显式设置position与z-index、避免意外创建层叠上下文。
视频或Canvas元素默认会创建独立的渲染层，导致 z-index 失效——这不是你CSS写错了，而是浏览器对媒体元素的特殊处理规则在起作用。
video 元素穿透遮罩层的典型表现
给 <video> 加了 controls 属性后，即使遮罩层 z-index: 9999、position: fixed，点击进度条/全屏按钮仍能穿透触发；更糟的是，在某些安卓 WebView 或旧版 Safari 中，遮罩甚至完全不可见。
- 根本原因：原生控件（尤其是
controls）运行在浏览器 UI 层，高于网页 CSS 渲染层 - 最直接解法是移除
controls属性，用 JS + 自定义 DOM 实现播放/暂停/音量等逻辑 - 若必须保留原生控件，可尝试加
playsinline+webkit-playsinline（iOS），再配合transform: translateZ(0)强制提升图层，但兼容性不稳 - 遮罩层需确保与
<video>同级或包裹它，且父容器不能有transform、filter、opacity < 1等意外创建 stacking context 的属性
Canvas 元素层级被“吃掉”的真实原因
Canvas 不参与文档流，也不响应 z-index 的常规堆叠顺序——它默认处于“合成层”，但具体层级取决于是否启用硬件加速、是否被其他元素的 transform 或 will-change 拉入更高图层。
- 常见错误：把
<canvas>放在position: relative容器里，又给兄弟元素设z-index: 10，结果 Canvas 总是压在上面 - 可靠做法：给 Canvas 和遮罩层都显式设置
position: absolute或fixed，并统一指定z-index（比如 Canvas 设为1，遮罩设为100） - 若 Canvas 用于视频水印或实时绘制，务必避免用
transform: scale()控制尺寸——这会触发新图层，干扰 z-index 顺序；应改用 JS 动态重设canvas.width/canvas.height并调用ctx.scale() - Chrome DevTools 的 “Layers” 面板能直观看到每个元素所属的合成图层，比猜
z-index更准
移动端 Safari 的定位失效叠加问题
iOS Safari 对 position: fixed + video + overflow: scroll 组合有已知渲染 bug：遮罩层可能随滚动错位，或被视频控件“顶出”视口。
立即学习“前端免费学习笔记（深入）”；
- 关键规避点：禁用
-webkit-overflow-scrolling: touch（它会让滚动容器创建独立合成层，打乱原有 stacking 顺序） - 替代方案：用
overscroll-behavior: contain控制滚动传播，或改用position: sticky+ 容器高度限制 - 不要依赖
top: 50%这类百分比定位——移动端视口高度常因地址栏显示/隐藏动态变化，应改用vh单位或 JS 动态计算 - 真机调试时，Safari 开发者工具的 “Rendering” 标签页下勾选 “Show paint rectangles”，能快速识别是否因图层分裂导致遮挡异常
真正决定层级的不是 z-index 数值本身，而是它所在的 stacking context 是否被意外切断——尤其当父容器用了 transform、opacity、filter 或 will-change 时，z-index 就只在那个子树里有效。这点容易被忽略，但几乎覆盖所有“明明写了 z-index 却没用”的场景。
