当视频或 Canvas 元素出现遮罩层被穿透、浮层失效或定位元素被遮挡的问题时，根本原因通常在于浏览器的特殊渲染机制：这类原生媒体元素运行在高于 CSS 渲染层的 UI 层。常见解决方案包括移除 controls、使用自定义播放控件、显式设置 position 与 z-index，以及避免无意中创建新的层叠上下文。
视频或 Canvas 元素往往会默认生成独立渲染层，这也是很多情况下 z-index 看似失效的关键原因——并不是 CSS 写错，而是浏览器针对媒体元素采用了不同于普通 DOM 的渲染策略。
video 元素穿透遮罩层的常见现象
当 添加了 controls 属性后，即使遮罩层设置了很高的 z-index: 9999，并配合 position: fixed，点击进度条或全屏按钮时仍可能直接穿透触发；在部分安卓 WebView 或老版本 Safari 浏览器中，遮罩层甚至会直接不显示。这是前端开发中非常典型的 video 遮罩失效问题。
- 核心原因：原生控件，尤其是
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 这一组合存在已知渲染问题：遮罩层可能在滚动时发生错位，或者被视频原生控件直接“挤出”视口。这也是移动端页面中视频遮挡 fixed 元素的高发原因之一。
- 关键规避方式：关闭
-webkit-overflow-scrolling: touch，因为它会让滚动容器生成独立合成层，从而打乱原有 stacking 顺序 - 替代思路：可用
overscroll-beha vior: contain控制滚动传播，或者改用position: sticky配合容器高度限制来实现类似效果 - 不要过度依赖
top: 50%这类百分比定位方式——移动端视口高度会随着地址栏显示和隐藏持续变化，更适合使用vh单位或通过 JS 动态计算定位 - 在真机调试时，可打开 Safari 开发者工具，在 “Rendering” 标签页勾选 “Show paint rectangles”，快速判断是否因为图层拆分导致遮挡、错位或层级异常
决定层级关系的，很多时候并不只是 z-index 数值本身够不够大，而是它所在的 stacking context 是否已经被意外“截断”。特别是当父容器使用了 transform、opacity、filter 或 will-change 时，z-index 的影响范围就会被限制在当前子树内部。这一点在处理 CSS 定位元素被视频或 Canvas 遮挡、z-index 不生效、遮罩层无效等问题时非常关键，也几乎可以解释大多数“明明设置了 z-index 却还是被压住”的场景。
