RGB数值反转不等于视觉反色，因人眼感知非线性且LCH亮度L值才是可读性核心，需按背景L+55原则动态调整文字亮度，mix-blend-mode: difference存在兼容与精度缺陷，JS计算亮度+CSS变量驱动才是可靠方案。
RGB数值反转 ≠ 视觉反色，人眼不认数学取反
直接把 rgb(30, 40, 50) 改成 rgb(225, 215, 205)（即每个通道用255减），在绝大多数场景下都会导致文字发灰、对比度崩塌、OLED边缘发虚。这不是计算错了，而是把“像素值运算”当成了“视觉感知映射”。人眼对明暗的响应是非线性的，尤其在暗背景下，rgb(200, 200, 200) 和 rgb(255, 255, 255) 的可读性差距远小于浅色模式下的 rgb(50, 50, 50) 与 rgb(0, 0, 0)。
反转RGB会破坏LCH亮度层级关系
LCH色空间里的 L 值（亮度）才是决定可读性的核心指标，而RGB三通道加权混合后才映射到L。简单相减完全无视这个权重：
-
rgb(0, 0, 0)→ L ≈ 0，反转得rgb(255, 255, 255)→ L ≈ 100，看似合理 -
rgb(30, 40, 50)→ 实际L ≈ 18（因B通道权重仅0.0722），反转得rgb(225, 215, 205)→ L ≈ 82，但该值在深灰背景上仍显闷、缺乏视觉重量 - 真正需要的是“背景L + 55”原则：若背景
L ≈ 20，文字L至少要 ≥75，对应更干净的去色灰白如rgb(220, 220, 220)，而非机械反转结果
mix-blend-mode: difference 看似自动，实则陷阱密集
有人用 mix-blend-mode: difference 想“绕过手动调色”，但它不是智能反色，只是像素级差值运算：
- 只接受纯黑
color: #000或纯白color: #fff输入，其他值会糊成不可控灰阶 - 要求背景是文字**直系父容器**的不透明纯色——
rgba(0,0,0,0.9)、background-image、opacity、transform都会导致失效 - Safari 15.4+ 才稳定支持；iOS 15.2 及更早版本直接忽略
- 滚动或动画中易出现瞬时错色，因重绘不同步
真正可靠的路径是JS算亮度 + CSS变量驱动
目前唯一兼顾准确性、可访问性与动态适配的方案，是把亮度判断交给JS，样式控制留给CSS：
立即学习“前端免费学习笔记（深入）”；
- JS用WCAG标准公式计算背景亮度：
0.2126 * r + 0.7152 * g + 0.0722 * b（归一化到0–1） - 通过
getComputedStyle(el).backgroundColor获取真实渲染色，再解析rgb()或hex - CSS中用
color-mix(in srgb, #000, #fff calc(var(--luma) * 100%))实现平滑黑白过渡，而非硬切 - 所有颜色必须收拢为CSS变量，否则无法运行时注入新值
最常被忽略的一点：深色模式下，::selection 不会继承父元素 color，必须显式声明 color 和 background-color，否则选中文本直接消失。
