纯CSS无法自动根据background-color计算反色，需通过CSS变量预设配对色值、媒体查询或JS判断明暗后设置class；推荐用data-theme控制多套主题色，避免filter: contrast()等误用。
background-color 变化时，color 怎么自动反色？
纯 CSS 没有“根据 background 自动算 contrast color”的原生能力。所谓“动态反色”，本质是提前约定好几组配对色值，再用 CSS 变量 + 类名/属性控制切换，不是实时计算。
常见错误是写 color: invert(1) 或幻想 color: contrast-to(background) —— 这些都不存在。浏览器不读取渲染后的背景色，也不做色彩空间转换。
- 真正能用的只有：CSS 自定义属性（
--bg/--text）手动绑定、prefers-color-scheme媒体查询、或 JS 读取getComputedStyle后回写（但非纯 CSS） - 如果背景色来自外部（比如用户上传图片、渐变动态生成），CSS 变量无法感知，必须交由 JS 判断明暗后加 class
- 深色模式下直接靠
@media (prefers-color-scheme: dark)覆盖变量更可靠，比试图“推导”安全得多
用 :root + data-theme 控制多套主题色
把背景和文字色拆成独立变量，在根节点定义默认值，再用 data-theme 属性批量切换——这是最可控、可维护性最高的做法。
例如深色背景配浅字、浅色背景配深字，不是靠算法猜，而是明确声明：
立即学习“前端免费学习笔记（深入）”；
:root {
--bg: #ffffff;
--text: #1a1a1a;
}
[data-theme="dark"] {
--bg: #121212;
--text: #e0e0e0;
}
body {
background-color: var(--bg);
color: var(--text);
}
- 不要在
:root里写background-color: var(--bg)—— 这会导致初始闪屏（CSS 变量未生效前用浏览器默认色） -
data-theme比 class 更利于 JS 控制，且不会和第三方 class 冲突 - 变量名保持语义（如
--text-primary、--surface），别用--color-1这类无意义命名
contrast() 函数根本不能用于文字颜色
contrast() 是 filter 函数，只作用于元素自身及其子元素的**渲染效果**，不改变 color 计算值，也不能当 color 值用。
写 color: contrast(2) 会直接失效（语法错误），写 filter: contrast(2) 则会让整个文字发灰/过曝，和可读性背道而驰。
-
filter影响的是绘制结果，不是样式计算逻辑；它无法解决文字在深色背景上发虚、在浅色背景上糊成一片的问题 - 真正提升对比度，请用 WCAG 推荐的明度差值（L1–L2 ≥ 4.5），而不是视觉滤镜
- 想模拟“高对比模式”，应监听
prefers-contrast: high媒体查询，换一套明确的色值，而非加 filter
JS 辅助判断明暗色并设置变量的边界在哪
只有当你无法预设所有背景色（比如 CMS 允许用户输入任意 hex）、且必须保证文字始终可读时，才需要 JS 介入。但它只是补位，不是首选。
核心逻辑是把十六进制转 HSL，取 L（Lightness），按阈值设变量：
const el = document.body;
const bg = getComputedStyle(el).backgroundColor;
const l = parseToLuminance(bg); // 需自己实现或用 tiny-color 等轻量库
el.style.setProperty('--text', l > 0.5 ? '#1a1a1a' : '#f0f0f0');
- RGB → 明度转换有多种算法（sRGB luminance vs HSL lightness），别用错；直接取
hsl().l不够准，推荐用 WCAG 官方公式 - 别在 scroll 或 resize 里反复调用——背景色不变时，计算一次就够了
- 服务端渲染（SSR）场景下，JS 判断会延迟，首屏仍可能对比失败；此时 fallback 到预设 class 更稳
变量绑定本身很简单，难的是决定什么时候信 CSS、什么时候必须交棒给 JS。背景色越不可控，就越得接受 JS 的侵入性——没有银弹，只有权衡。
