mix-blend-mode: difference 看起来像“响应式反转”实为像素级差值运算 |R₁−R₂| 的视觉结果，并非检测背景色；需满足文字与背景相邻、父容器无 opacity/filter/transform 干扰、文字用纯黑或纯白三条件，否则失效。
mix-blend-mode: difference 为什么看起来像“响应式反转”
它根本不是响应式，也不检测背景色——mix-blend-mode: difference 只是对文字图层和其正下方图层做逐通道差值运算：|R₁ − R₂|。纯黑文字（#000000）在深色背景上算出高亮色，在浅色背景上算出暗色，视觉上“自动切换”，但底层没任何条件判断。所谓响应式，其实是渲染引擎实时重绘的结果，不是 CSS 主动适配。
必须满足的三个硬性结构条件
90% 的失效都源于 DOM 层级或 stacking context 断裂：
- 文字和背景必须处于**相邻图层**：要么文字是带背景容器的直接子元素（如
<div style="background:#222"><p>文本</p></div>），要么用伪元素::before绘制背景并设z-index: -1 - 父容器不能有
opacity、filter、transform或isolation: isolate——哪怕值是opacity: 0.99或filter: blur(0)，都会隐式创建新 stacking context，切断混合链路 - 文字必须用不透明纯色：
color: #000000或color: #ffffff；用#666、hsl(0,0%,50%)或带 alpha 的rgba()，结果会发灰、糊边、对比度崩盘
@supports 和移动端 Safari 的真实兼容底线
mix-blend-mode: difference 在 Safari 上尤其脆弱：
- iOS 15.2 及更早版本完全忽略该声明，回退为默认文字色，且无任何降级提示
- iOS 15.4+ 才稳定支持，但对
position: fixed或position: sticky元素仍有闪烁、错位、滚动中短暂消失等问题 - 必须用
@supports (mix-blend-mode: difference)包裹，否则旧版 WebView（如 Android 69）会直接跳过规则，导致文字不可读 - 别信“现代浏览器都支持”的说法——真机测试时重点看滚动过程中的文字是否突然变灰或闪退，这是 Safari 渲染管线重排的典型表现
中灰背景下的对比度陷阱与兜底逻辑
当背景是 #808080（明度 0.5），difference 运算后 #ffffff 变成 #7f7f7f，对比度仅约 1.05:1，远低于 WCAG AA 要求的 4.5:1。这不是 bug，是数学必然：
立即学习“前端免费学习笔记（深入）”；
- 无法靠 CSS 自身修复——
color不支持基于背景色的条件计算 - 唯一可靠兜底：用 JS 计算背景明度（
(0.299 * r + 0.587 * g + 0.114 * b) / 255），明度 --text-color: #fff，否则--text-color: #000，再通过color: var(--text-color)控制 - 动态背景（如用户上传图、CSS 动画渐变）必须重新触发 JS 计算；
mix-blend-mode在这类场景下结果不可控，甚至生成肉眼难辨的中间灰
真正容易被忽略的是 stacking context 的隐式创建——哪怕只是给父容器加了个 opacity: 0.99，都可能让混合失效。动手前先打开 DevTools，检查 computed styles 里的 isolation 和 will-change 状态，不是看有没有写，而是看浏览器实际是否创建了新层。
