直接改--color-primary就能全局生效，因其在:root定义后所有var()实时读取该值；必须在:root声明、语义化命名、分层组织并配fallback，避免硬编码与命名冲突。
直接改 --color-primary 就能同步所有用到它的组件，不用 grep 全项目找 #007bff —— 这是协作效率提升最实在的落点。
为什么改一处变量就能全局生效
CSS 变量是运行时计算的，所有 var(--color-primary) 都实时读取 :root 里定义的值。设计师说“主色从蓝变紫”，你只改一行：--color-primary: #6b21a8;，按钮、标题、边框全跟着变。
硬编码则完全不同：同一色值可能散落在 button.css、card.scss、form.less 甚至内联样式里，漏改一处就导致视觉不一致。
- 必须在
:root中声明，否则组件里var(--color-primary)会 fallback 到浏览器默认值（比如currentColor），页面加载时闪一下再变色 - 别在组件作用域里重定义同名变量，比如
.card { --color-primary: red; }—— DevTools 里看不出最终值来自哪，协作排查成本陡增 - 变量值必须语义化，写
--color-primary而不是--blue-500，否则换主题时得批量重命名、改引用、同步设计系统文档
--color-primary 这类名字怎么避免撞车
大型团队里，--primary-color 这种名字一写就冲突：A 组改了它，B 组的弹窗边框突然变色，没人知道谁动的。
立即学习“前端免费学习笔记（深入）”；
按功能域+层级切分命名空间才是解法：
- 基础色：用
--color-blue-500、--color-gray-200，仅用于设计 Token 映射，不直接在组件里引用 - 语义色：用
--color-primary、--color-border-divider，表达用途而非色值，组件里只用这类 - 组件色：用
--btn-primary-bg、--input-border-hover，绑定具体 UI 元素，避免跨组件污染
禁用 --main、--dark 这类抽象名——深色模式下它们根本无法区分语义，CI 校验也难定位问题。
变量和 BEM 类名怎么配合不打架
BEM 类名不该出现颜色字眼，比如 button--red 或 card--blue。这不是语义，是外观快照，设计一改就得批量重命名 HTML、JS 和 CSS。
正确做法是让 BEM 表达意图，变量控制颜色：
- 类名只写状态：
button--primary、card--featured - 样式里用变量驱动：
button--primary { background-color: var(--color-primary); } - 原子类（如
.text-error）可以内部写color: red;，但仅限文档示例或极简工具类，业务组件一律走变量
调试时用 DevTools 临时覆盖，别把 red 写进类名里 —— 那不是协作，是给后续所有人埋雷。
:root 里变量怎么组织才不乱
:root 不是随便堆变量的地方。必须分组 + 注释 + fallback：
- 按逻辑分组：主题色、状态色、文字色、背景色、边框色，每组前加注释
/* -- Theme Colors -- */ - 每个变量带 fallback：
--color-primary: #007bff; /* fallback for legacy */，防止未定义时样式崩塌 - 值格式统一校验：CI 里跑正则检查是否全是十六进制或 rgb()，禁用
rebeccapurple这类命名色（JS 无法读取计算值，主题切换逻辑会断）
真正容易被忽略的是 fallback 的实际效果：如果 var(--color-primary, #000) 里 fallback 是纯黑，而设计稿主色是紫色，那未加载完成时用户看到的就是错的对比度——这比闪屏更伤体验。
