对比色≠反色，需按WCAG亮度公式计算相对亮度并确保对比度≥4.5；CSS新函数color-mix()+relative-color()可实现背景驱动的文字色自动切换，但须配合@property声明；降级用light-dark()和prefers-contrast；JS计算需注意透明度与真实渲染色获取。
对比色不是“反色”，别直接用 hsl() 调整色相±180
很多人以为把 hsl(120, 70%, 50%) 改成 hsl(300, 70%, 50%) 就得到对比色，其实这是补色（complementary），视觉上未必可读。真正影响文字可读性的是亮度差和色相差，尤其在深色背景上白字不总比黑字好——比如浅黄背景配白字就接近失效。
浏览器原生没有 contrast-color() 这类函数，必须靠逻辑判断+计算。核心依据是 WCAG 2.1 的相对亮度公式（L = 0.2126*R + 0.7152*G + 0.0722*B），再套用对比度比值 (L1 + 0.05) / (L2 + 0.05) ≥ 4.5 才算达标（AA级）。
用 color-mix() + relative-color() 在支持的浏览器里做轻量级自动切换
Chrome 111+、Safari 16.4+ 已支持 CSS 颜色函数新特性，可以绕过 JS 实现纯 CSS 方案。关键不是“生成对比色”，而是“根据背景亮度选择预设的黑或白”。
-
relative-color()能提取当前颜色的l（LCH 中的亮度通道），比旧式rgb()解析更准确 -
color-mix()可以按亮度插值：比如背景越暗，文字越倾向白色；但不能直接 mix 出“新颜色”，只能混合两个已知色 - 必须配合
@property声明自定义属性为 color 类型，否则relative-color()无法解析变量
@property --bg {
syntax: '<color>';
inherits: false;
initial-value: #4a6fa5;
}
<p>.card {
background-color: var(--bg);
color: color-mix(in lch, white 70%, black 30% calc(100% - l(relative-color(var(--bg) l))));
}注意：l(relative-color(...)) 返回的是 0–100 的 LCH 亮度值，需手动映射到 mix 比例（例如 l=30 → 白占 70%）。
立即学习“前端免费学习笔记（深入）”；
降级方案：用 prefers-contrast 和 light-dark() 应对系统级偏好
当无法用 JS 或新 CSS 函数时，优先利用系统信号。这不是“生成”，而是“委托”：
-
light-dark(black, white)仅适用于color属性，且只响应系统深色模式开关，不感知具体背景色 -
@media (prefers-contrast: high)可触发高对比模式，此时建议强制用纯黑/纯白，禁用灰阶文字 - 二者叠加使用时，
light-dark()优先级低于媒体查询，所以要把高对比逻辑写在后面
.text {
color: light-dark(black, white);
}
@media (prefers-contrast: high) {
.text { color: black; }
}真要动态计算？JS 仍是目前最稳的选择，但别在渲染时实时调用 getComputedStyle
CSS 无法读取元素实际渲染后的背景色（尤其是渐变、伪元素、filter 后效果），所以前端库如 chroma.js 或手写亮度计算，都得基于你“传进去的值”，而非“页面上看到的色”。常见坑：
- 传入
#fff没问题，但传入rgba(255,255,255,0.8)就得先转成带 alpha 的 RGB 计算，否则忽略透明度导致亮度误判 - CSS 变量若来自 :root，可用
getComputedStyle(document.documentElement).getPropertyValue('--bg')，但返回值可能是 rgb() 字符串，需正则提取数字 - 避免每帧调用：把颜色计算结果缓存到 data 属性或 CSS 自定义属性中，用
element.style.color = computedTextColor直接设置
真正难的从来不是“怎么算”，而是“你拿到的到底是不是用户最终看到的那个背景色”——阴影、backdrop-filter、mix-blend-mode 都会让理论值失效。
