Firefox完整支持mask-composite全部值，Chrome/Edge虽识别关键词但忽略语义、始终按add逻辑合成，根源在于该属性属CSS Masking Level 1“at-risk”特性，Blink引擎尚未实现可配置合成模型，生产环境应降级使用SVG<mask>或clip-path。
mask-composite 的浏览器兼容性现状很现实
它不是“不支持”，而是“支持但默认行为不一致”——mask-composite 在 Firefox 完整实现全部值（add/subtract/intersect/exclude），而 Chrome/Edge 目前只识别这些关键词，但**忽略其语义**，始终按 add（即累加）逻辑合成，哪怕你显式写了 mask-composite: subtract。
更关键的是：mask-composite 的初始值确实是 add，但 Chrome 实际执行时用的是底层的 source-over 合成模型，虽效果常与 add 重合，但在多层 alpha 边界叠加、半透明遮罩交叠等边界场景下，仍可能产生像素级差异。
为什么 Chrome 不按规范走？
这不是 bug，是实现优先级问题。CSS Masking Level 1 规范中 mask-composite 属于“at-risk”特性（风险特性），Chrome 团队尚未将其列为高优先级实现项。当前 Blink 引擎对多层 mask-image 的合成逻辑固化在 rasterization 阶段，未暴露可配置的 Porter-Duff 或非 Porter-Duff 合成入口。
这意味着：
立即学习“前端免费学习笔记（深入）”；
- 你在 Chrome 中写
mask-composite: intersect，DevTools 会显示该声明“已应用”，但渲染结果和没写一样 - Firefox 可以正确裁剪出两层遮罩的交集区域，Chrome 则直接叠加显示（等效于
add） - 即使所有
mask-image都是纯黑白（无灰度），Chrome 依然不触发subtract的“打孔”行为
如何验证 mask-composite 是否真生效？
别只看视觉，用 DevTools 的 Rendering 面板 + “Layer Borders” 和 “Paint Flashing” 配合检查：
- 在 Firefox 中，设置两层 SVG 遮罩（一个圆、一个矩形），分别用
mask-composite: subtract，观察元素内容是否真的在矩形区域内被挖空 - 在 Chrome 中做同样操作，用
getComputedStyle(el).maskComposite检查返回值——它会返回"subtract"，但渲染层没有对应行为 - 用
canvas绘制相同遮罩逻辑作基准比对，能快速定位是 CSS 渲染偏差，而非设计预期错误
现在能靠它做生产环境的复杂遮罩吗？
不能直接依赖。目前最稳妥的路径是：
- 单层遮罩：完全可用，
mask-image+mask-size+mask-position在主流浏览器一致 - 多层遮罩且需精确合成逻辑：降级为 SVG
<mask>内使用<use>+mask-composite（SVG 原生支持更早，Chrome 也认） - 必须用 CSS 多层遮罩：只用
add（或省略），并确保设计不依赖subtract/intersect的语义 - 需要“打孔”效果：改用
clip-path的path()或inset()组合，兼容性更好
真正容易被忽略的点是：很多人在 Firefox 里调通了 exclude 效果，就以为上线没问题，结果用户打开 Chrome 发现整个遮罩区域全黑——因为 Chrome 把所有层都当 add 累加，而叠加后的 alpha 值溢出导致全透明失效。这种隐性 fallback 行为，必须在多浏览器实机测试阶段卡死。
