基础色是UI骨架，如primary、neutral等语义化变量；辅助色为特定功能服务，如link、border、shadow，需按用途分层声明，避免混用导致维护混乱。
怎么定义基础色和辅助色才不容易混乱
基础色是整个 UI 的骨架，比如 primary、neutral 这类语义化变量；辅助色则是为特定功能服务的，比如 link、border、shadow。很多人一开始就把所有颜色全塞进 :root，结果改个按钮背景时发现 primary 同时被用在文字、边框、悬停态上，一动全崩。
建议按用途分层声明：
-
--color-primary只用于主操作按钮、高亮标签等“有行为意图”的元素 -
--color-neutral-100到--color-neutral-900用于文字、背景、分割线，不参与交互逻辑 -
--color-link独立于primary，哪怕视觉上相同，也该单独定义——因为链接未来可能要加下划线或 hover 变色 - 避免用
--color-blue-500这类纯数值命名，除非你真在做设计系统工具链；业务项目里直接叫--color-primary更安全
CSS 中警告色和成功色的命名与使用边界
警告色不是“黄色”，成功色也不是“绿色”——它们是状态信号，必须和语义绑定。常见错误是把 success 当成“好看绿”，结果在表单提交成功提示里用了它，又在数据图表里复用同一个变量表示“达标”，用户根本分不清哪一个是反馈、哪一个是数据映射。
实操要点：
立即学习“前端免费学习笔记（深入）”；
-
--color-success只用于操作结果反馈（如“保存成功”）、状态 badge（如“已发布”） -
--color-warning仅用于需用户注意但不阻断流程的情况（如“剩余配额不足”），别用在 disabled 按钮上 - 如果图表需要绿色/红色表达趋势，应该用
--color-chart-up/--color-chart-down，和状态色完全隔离 - 别为了省事让
success和warning共享同一组亮度梯度；它们的可读性要求不同——警告常需更高对比度来触发注意
为什么不能直接用 HSL 或 HWB 写基础色变量
HSL 看着直观，但浏览器对它的解析稳定性差，尤其在 CSS 自定义属性嵌套计算时容易出错；HWB 更新，但 Safari 16.4 之前根本不支持。更现实的问题是：设计师给的色值基本都是 HEX 或 RGB，你硬转成 HSL 后，下次换主题时想调亮度？得反推回 RGB 再算一遍，中间还可能因舍入误差偏色。
- 基础色变量统一用
rgb()或十六进制（如#007bff），保证跨浏览器一致性 - 需要明暗变化时，用
color-mix()或color()函数动态生成，而不是靠 HSL 的lightness参数硬调 - 如果必须用 HSL（比如做深色模式自动变暗），至少加上降级：
color: #007bff; color: hsl(206, 100%, 40%) - 别在
:root里写hwb(206 0% 30%)——它在旧版 Chrome 和所有 IE 里直接失效，且无法 fallback
深色模式下警告色和成功色要不要换
要换，但不是简单“变暗”。原样照搬浅色模式的 success（比如 #28a745）到深色背景上，对比度会暴跌，AA 级都不达标；而直接加黑（#1a7530）又会让它失去“积极”感知。
- 测试工具比直觉靠谱：用
color-contrast()函数或在线对比度检测器，确保深色模式下--color-success在--color-neutral-900背景上 ≥ 4.5:1 - 推荐做法：保留色相，调整亮度和饱和度——比如浅色模式用
#28a745，深色模式用#4ade80（更亮、稍高饱和），而非同色相的暗版本 - 别让
warning在深色模式下变成棕黄（#f59e0b→#d97706），它容易被误读为“disabled”，换成带橙红倾向的#fb923c更醒目 - 最易忽略的一点：border 和 icon 的成功/警告色也要同步更新，不能只改文字色——否则按钮内部文字合格了，边框却糊成一片
颜色分类不是贴标签，是建约束。一旦某个 --color-warning 开始出现在 loading 动画或空状态图里，整套逻辑就松动了。
