根本原因是 overflow: hidden 的裁剪与 mix-blend-mode 的混合逻辑冲突：混合需访问被裁剪内容的完整像素，而 overflow 提前截断渲染上下文，导致混合失效或裁剪失灵。
mix-blend-mode + overflow: hidden 为什么失效
根本原因是 overflow: hidden 的裁剪行为与 mix-blend-mode 的混合计算逻辑冲突：混合需要访问“背后内容”的完整像素区域（包括被裁剪掉的部分），而 overflow: hidden 会提前截断渲染上下文，导致浏览器无法获取足够像素完成 blend 运算。结果就是——裁剪没生效，或混合完全不触发。
常见现象：overflow: hidden 在父容器上写了，但子元素用了 mix-blend-mode: screen 后，依然能看到超出边界的混合溢出；或者反过来，混合突然消失，DevTools 显示 computed overflow 是 hidden，但视觉上毫无裁剪痕迹。
- 不要给
<video>或其直接父级设overflow: hidden—— 它会破坏视频层与背景的混合通路 -
overflow: hidden和isolation: isolate不能共存于同一容器：前者限制像素范围，后者扩展混合上下文，浏览器会优先丢弃混合 - 若必须裁剪又必须混合，得把裁剪和混合拆到不同层级：用外层容器
overflow: hidden包裹，内层容器加isolation: isolate并设position: relative，确保混合发生在内层内部
强制 GPU 渲染反而让 overflow 失效？
是的。加 transform: translateZ(0) 或 will-change: transform 确实能“强制提升图层”，但同时也切断了 overflow: hidden 的裁剪作用域——因为新合成层拥有独立的绘制边界，overflow 规则只对原层叠上下文有效，对 GPU 图层无效。
典型错误操作：.blend-wrapper { overflow: hidden; transform: translateZ(0); } → 此时 overflow 形同虚设，混合可能生效，但裁剪彻底失效。
立即学习“前端免费学习笔记（深入）”；
- 想兼顾混合与裁剪，优先用
contain: paint替代will-change：它轻量、不新建合成层，且不影响overflow行为 - Chrome/Firefox 中可用
clip-path: inset(0)替代overflow: hidden，它在 GPU 图层下仍有效，且与mix-blend-mode兼容性更好 - Safari 下更激进：必须用
transform: translateZ(0)提升混合元素本身（不是父级！），同时把overflow: hidden移到祖父级，并确保该祖父级没触发 stacking context
真正可控的 overflow + mix-blend-mode 组合方案
没有“一键修复”，只有分层控制。核心原则：裁剪和混合不能落在同一个元素上，也不能由互相冲突的属性共管。
- 结构上分离职责：
.crop-container { overflow: hidden; }<br>.blend-container { isolation: isolate; }，且两者不能是父子直系（中间至少隔一层无特殊样式的<div>） - 避免在任何含
mix-blend-mode的元素上写overflow—— 即使是visible，某些内核也会隐式干扰混合通路 - 移动端真机调试时，打开 Chrome 的
Layers面板，确认overflow: hidden对应的裁剪矩形是否覆盖了混合区域；若没覆盖，说明它被提升图层绕过了 - 如果背景是
background-image，别试图用mix-blend-mode让文字和它混合——改用background-blend-mode+background-color叠加，它天然支持overflow
最常被忽略的一点：overflow: hidden 的裁剪能力依赖于元素是否参与正常文档流。一旦你给它加了 position: absolute 或 transform，它就大概率失去裁剪效力，无论 mix-blend-mode 是否启用。
