硬编码颜色值导致修改散落多文件，而css变量如--color-primary只需改一处即可全局同步；变量名须语义化（如--color-border-divider），禁用--blue-500等含色值或组件绑定的命名；:root必须声明默认值并配fallback，避免闪屏与调试混乱。
因为硬编码颜色值会让修改散落在几十个文件里，而 --color-primary 只需改一处，所有引用自动同步——协作失控的根源不是人不认真，是没把变更收敛到一个可控入口。
变量名必须语义化，不能带具体色值或层级信息
写 --blue-500 或 --main-btn-bg 是埋雷：前者换主题时全得重命名，后者绑定组件逻辑，导致按钮样式和颜色体系耦合。真正该用的是 --color-primary、--color-border-divider 这类只表达用途的命名。
- 设计师说“主色从蓝变紫”，你只需改
:root里一行，不用 grep 全项目找#007bff -
--color-text-disabled比--gray-400更可靠：它明确告诉别人这是“禁用态文字色”，而不是某个色卡上的位置 - 避免在组件作用域里重复定义同名变量，比如
.card { --color-primary: red; }—— DevTools 里根本分不清最终值从哪来
:root 必须声明默认值，否则页面加载会闪或失色
常见错误是只在 [data-theme="dark"] 或 @media (prefers-color-scheme: dark) 里覆盖变量，却忘了 :root 本身要先有默认值。浏览器解析 CSS 是逐行进行的，没默认值就等于没定义，var(--color-text) 直接 fallback 到空字符串，文本可能瞬间不可见。
- 正确顺序：先写完整亮色模式的
:root块，再用媒体查询或属性选择器覆盖差异项 - 每个
var()都要带字面量 fallback：color: var(--color-text, #333)，别用red这种模糊值 - 禁用
!important覆盖变量——它会切断 JS 动态修改能力，比如document.documentElement.style.setProperty('--color-primary', '#ff0000')就失效了
rgb() / alpha 新语法对协作的真实影响
rgb(255 0 0 / 0.5) 不是炫技，它把颜色和透明度绑在一个函数里，避免 color 和 opacity 分开调导致子元素意外变淡。但团队必须统一采用，否则 CI 流水线会出问题。
-
rgb(255, 0, 0) / 0.5是无效写法，浏览器直接忽略整条声明 - Stylelint 插件
plugin/stylelint-color-function-unit可拦截混用行为 - JS 读取
getComputedStyle(el).color返回的仍是计算后值（如rgb(255, 0, 0)），alpha 不参与计算，这点和旧式rgba()一致
最难的不是写对语法，而是让十个人在同一个 PR 里改 :root 时不互相覆盖、不漏加 fallback、不把语义名写成色值缩写——这些靠工具拦不住，得靠 Code Review 和落地的规范检查点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
