from + calc() 是调色板生成的最小必要组合，因为 from 仅解构颜色通道，calc() 才能动态运算生成新色；单独用 from 只是复读原色，所有深浅、透明等变体均依赖 calc() 对通道值运算。
单独写 rgb(from var(--primary) r g b) 或 hsl(from #3b82f6 h s l) 不会生成新颜色，它只是“原样复读”——真正能动态衍生调色板的，必须搭配 calc() 对通道值做运算。
为什么 from + calc() 是调色板生成的最小必要组合
from 本身不改变颜色，它只把输入颜色解构成可访问的通道变量（比如 r、l、c），这些变量在没被 calc() 修改前就是静态数字。没有 calc()，你就只是在重复写同一个颜色。
- 常见错误现象：
color: hsl(from var(--primary) h s l);→ hover 颜色和默认色完全一样 - 你以为写了
from就自动“变暗”，其实什么都没算 - 所有深浅、透明、补色、对比色变体，都依赖对通道做加减乘除
用 hsl() 生成基础 UI 调色板：亮度/饱和度偏移最稳
HSL 在日常组件中兼容性最好、语义最直观，l（亮度）和 s（饱和度）直接对应“明暗”“鲜艳度”，适合生成 hover / active / disabled 状态色。
- 按钮悬停变暗：
background: hsl(from var(--primary) h s calc(l - 10));（注意：HSL 的l是 0–100 数值，不带%） - 禁用态降饱和+提亮：
color: hsl(from var(--primary) h calc(s * 0.3) calc(l + 15)); - 避免
l超出范围：calc(l - 10)在l原值为 15 时会得 5，安全；但calc(l - 30)可能到负数，浏览器会 clamp，结果不可控
用 oklch() 生成高保真调色板：L 和 C 解耦更准，但要降级
oklch() 的 L（亮度）和 C（色度）是正交设计，调亮度几乎不影响色相感知，做文字对比度适配或 WCAG 合规检查更可靠。但它目前 Safari 不支持 oklch() 函数。
立即学习“前端免费学习笔记（深入）”；
- 安全写法必须包裹
@supports：button { color: hsl(from var(--primary) h s calc(l + 20)); }@supports (color: oklch(0 0 0)) { button { color: oklch(from var(--primary) calc(L + 0.08) C H); } } -
L是 0–1 小数（不是百分比），C无固定上限，实测中calc(C * 0.7)通常比calc(C - 0.1)更稳定 - 别在
oklch()里强行改H（色相）做补色：数值跳变大，容易跨过视觉断层，不如用lch()或直接预设
绕不开的语法细节：空格、斜杠、单位一个都不能错
新版颜色函数对格式极其敏感，错一个空格或漏一个 / 就整个声明失效，浏览器直接忽略。
- alpha 必须用
/引入：rgb(from #000 r g b / 0.6)✅，rgb(from #000 r g b, 0.6)❌，rgb(from #000 r g b 0.6)❌ - 通道之间只允许空格，不能有逗号或等号：
hsl(from var(--c) h s calc(l + 10))✅，hsl(from var(--c), h, s, calc(l + 10))❌ -
calc()内部禁止单位（如10%）：calc(l + 10)✅（HSL 的l是纯数字），calc(l + 10%)❌ - RGB 通道是整数 0–255，
calc(r * 0.8)可能得小数，浏览器会四舍五入，但别依赖它精确控制
真正难的不是写出一行 hsl(from ...)，而是想清楚哪个通道该动、动多少才符合视觉预期——比如调 l 10 点在蓝色上很自然，在黄色上可能就发灰；OKLCH 的 L 偏移更线性，但得先处理 Safari 降级。这些没法靠语法自动解决，得靠人眼校验。
