颜色变量应按语义角色命名（如btn-primary-bg），避免直觉色名或混用位置与状态，css变量需加项目前缀、统一用color作二级关键词，主题切换宜用hsl动态生成，命名须与设计稿图层对齐。
颜色变量名别用“red”“blue”这种直觉型命名
直接用 red、primary-blue 这类名字，半年后你自己都得查一遍哪个 light-blue-2 是按钮悬停色、哪个是禁用文字。命名本质是给团队（包括未来的你）留线索，不是记颜色值。
- 按语义角色命名，比如
btn-primary-bg、text-disabled、border-focus—— 看名字就知道它在哪用、起什么作用 - 避免带具体色彩词的中间层变量，像
$blue-500看似规范，但一旦设计系统换主色，所有依赖它的组件都要改，反而增加耦合 - 如果真需要存色值，用中性前缀 + 色相+明度组合，例如
$color-brand-base、$color-neutral-light，而不是$color-blue-dark
CSS 自定义属性（CSS 变量）命名要带作用域前缀
不加前缀的 --primary 在大型项目里极易冲突，尤其引入第三方 UI 库时，对方也可能定义同名变量。CSS 变量是全局的，没模块隔离。
- 统一加项目或组件前缀，例如
--myapp-primary-color、--card-border-radius - 颜色变量建议统一用
color作二级关键词，如--myapp-color-text-primary，比--myapp-text-color更易被 IDE 自动补全识别 - 不要把语义和用途混在同一个变量里，比如
--header-bg-active这种名字，既说位置又说状态，后期想复用到 footer 就卡住
主题切换场景下，别把颜色变量和主题逻辑写死在 :root 里
很多团队一上来就在 :root 定义所有颜色变量，等要做深色模式时才发现：每个颜色都得手动写两套，且无法动态计算（比如自动变暗 10%），维护成本爆炸。
- 把基础色值抽成独立变量，例如
--color-brand-hue: 210、--color-brand-sat: 80%，再用hsl()动态生成，主题切换只需改几个数字 - 避免直接在 CSS 中写
color: var(--color-primary)后又靠 JS 切换 class 来换主题 —— 这样无法利用 CSS 的层叠优先级做 fallback，出错难定位 - 深浅模式共用一套语义变量名，比如始终用
--color-text-primary，只是背后hsl()的l值不同，而不是另起一套--color-text-primary-dark
设计系统交付时，颜色变量名必须和 Figma/设计稿中的图层命名对齐
设计师标注 “Text / Primary”，前端却写了 --text-main，同步成本就藏在这一个词的偏差里。不是谁迁就谁，而是命名规则要在协作起点就约定好。
立即学习“前端免费学习笔记（深入）”；
- 统一采用 “层级 / 角色” 格式，例如
Surface / Card / Background→--surface-card-bg，斜杠转连字符，全部小写 - 禁止使用缩写，
--txt-pri或--c-bg这类名字在 PR 评审或线上 debug 时等于没写注释 - 如果设计稿里有 “State / Hover”，变量就叫
--btn-primary-bg-hover，而不是自己发挥写成--btn-primary-hover-bg—— 顺序错一点，搜索和理解成本就翻倍
真正难的不是起名，是让所有人——设计师、前端、甚至产品——在看到 --form-input-border-error 时，脑内立刻浮现那个红色边框的位置和触发条件。名字一旦脱离上下文就失效，而上下文只存在于协作习惯里。
