hsl(from ...) 是生成动态互补色的首选方案，支持现代浏览器，能自动提取并运算色相，避免手动转换；旧版浏览器需 PostCSS 预编译或手写 fallback。
用 hsl(from ...) 直接加减色相最可靠
现代浏览器（Chrome 111+、Safari 16.4+、Firefox 115+）支持 hsl(from <color> ...)</color> 语法，这是生成互补色或类比色的首选方式。它能自动从任意颜色（十六进制、rgb、named color）中提取 HSL 分量，再对 h 做算术运算，无需手动转换或预计算。
常见错误是写成 hsl(calc(120 + 180), 70%, 60%) —— 这只适用于已知色相值的静态场景；一旦主色改了，就得手动更新所有派生色。而 hsl(from var(--primary) calc(h + 180) s l) 是真·动态：主色一换，互补色自动跟着变。
-
h是无单位数值，可直接参与calc()，比如calc(h + 180)、calc(h - 120) - 结果会自动模 360（如
h: 350→calc(h + 180)=530，但浏览器内部会处理为170） - 不支持旧版 Edge 或 Firefox 114 及更早版本，需检查目标环境
color-mix(in hsl longer hue) 不适合互补色
虽然 color-mix() 听起来像“混合出对面颜色”，但它在 hsl 空间里用的是 longer hue 模式，行为不可控：它会选绕远路的弧（>180°），而不是固定 ±180°。例如主色 h: 10°，longer hue 可能给出 190°，也可能给出 -170°（取决于实现），结果不稳定。
更关键的是：color-mix() 要求两个具体颜色值，不能用 var(--primary) 或 currentcolor，丧失变量灵活性。
立即学习“前端免费学习笔记（深入）”；
- 想用
color-mix()？只推荐做线性插值（如悬停加深），别碰互补逻辑 -
in srgb最兼容，但不是色轮运算；in lch更感知均匀，但 Safari 当前不支持 - 权重必须显式写出，
color-mix(in srgb, #2563eb 70%, #1e40af 30%)才有效，漏掉权重会默认 50%/50%
旧浏览器 fallback 必须手动预计算
如果你的项目还要支持 Chrome 110 以下、Safari 16.3 或旧版 Firefox，hsl(from ...) 会完全失效，CSS 将忽略整条声明。这时没有运行时方案，只能构建时解决。
PostCSS 是最实用的选择：用 postcss-hsl-calc 或自定义插件，在打包阶段把 hsl(from #2563eb calc(h + 180) s l) 展开成 hsl(205, 70%, 55%) 这样的纯值。
- JS 方案（如读取
getComputedStyle再计算）可行，但有 FOUC 风险，且无法用于伪元素或未挂载元素 - 不要依赖
@property+calc(var(--hue)/1deg + 180)做 fallback：它需要 Chrome 117+ / Safari 16.4+，和hsl(from ...)的支持范围基本重叠 - 手动生成一组固定互补色（如
#2563eb→#f97316）并写死，是最简单但最脆弱的 fallback
明度和饱和度调整比色相更影响可访问性
很多人只盯着 h 加减，却忽略 l（亮度）和 s（饱和度）对实际可用性的决定性作用。互补色本身对比强，但如果 l 太高（如 95%）或太低（如 10%），文字可能根本达不到 WCAG 4.5:1 对比度要求。
一个被反复验证的模式是：互补色用作背景/边框时，保持原色的 s 和 l；用作文本色时，降低 s（到 30–50%）、微调 l（到 20–40%），避免刺眼或发灰。
-
hsl(from var(--primary) calc(h + 180) calc(s * 0.6) calc(l * 0.8))比裸加 180 更实用 - 避免对
l做绝对加减（如calc(l + 25)），深色基底上会溢出到 100%，变成不可读的白 - 动画
hsl()明度时，Chrome 和 Firefox 插值路径不同，可能导致视觉跳变，慎用
真正麻烦的从来不是怎么算 180 度，而是算完之后——那个“互补”出来的颜色，在真实 UI 里是否足够可读、是否在深色模式下依然成立、是否在旧设备上干脆不显示。这些没法靠一行 calc() 解决，得结合设计约束一起判断。
