直接写#3498db让维护困难，因其无业务语义，导致理解成本高、主题切换难、多处重复定义且易遗漏；应使用语义化CSS变量如--text-primary，并按功能+状态命名，分层管理，渐进替换，注意兼容性与性能。
颜色值直接写#3498db为什么会让维护变困难
因为十六进制或RGB值本身不携带业务含义，下次看到#e74c3c时，你得翻三遍代码才能确认这是“删除按钮悬停色”还是“表单错误边框”。团队协作中，这种写法会放大理解成本，尤其在主题切换、深色模式适配或设计系统迭代时，改一个颜色要全局搜、逐个试、反复验证。
- 同一语义可能分散在多个文件：按钮、输入框、警告提示各自定义
#e74c3c，但没人知道它们本该一致 - 设计师给新色值后，开发者容易只改了
button.css却漏掉alert.css - 无法通过变量名快速判断用途：
--primary比--color-12或--blue-500更贴近业务场景（比如--brand-accent）
用:root定义CSS变量的命名要点
CSS变量名不是越短越好，也不是照搬设计稿的“蓝色500”，关键是要让名字能回答“这个颜色用在哪、为什么是它”。避免纯描述性命名（如--light-blue），优先绑定语义角色。
- 基础层用功能+状态组合：
--text-primary、--bg-surface、--border-disabled - 组件层可细化，但不冗余：
--button-primary-bg（不是--button-primary-background-color） - 禁用带具体值的命名：
--color-ff6b6b、--blue-300——这类名字在换主题时会立刻失效 - 深色模式下复用同一变量名，仅在
@media (prefers-color-scheme: dark)里重定义值，而不是另起--text-primary-dark
var(--text-primary)在实际项目中的替换节奏
别想着一次性把所有颜色值全替成变量。先锁定高频、高耦合、易变更的颜色点，再逐步下沉。否则容易卡在“改一半就出问题”的状态。
- 第一轮只动全局通用色：文字主色、背景主色、关键操作色（如
--cta-primary） - 第二轮处理组件级变量：确保
Button、Input、Alert都引用同一套--text-error而非各自写#e74c3c - 如果项目还在用CSS预处理器（如Sass），别混用
$primary-color和--primary-color——运行时CSS变量无法被Sass函数处理，会导致计算错误 - 检查构建工具是否清除未使用的CSS变量：Webpack/Vite默认不删，冗余变量会留在生产包里
浏览器兼容性和var()回退写法的实际影响
CSS变量在IE中完全不支持，哪怕加了fallback，IE也会忽略整条声明。所以如果你还要兼容IE，就不能只靠var()，必须配合预编译或JS注入。
立即学习“前端免费学习笔记（深入）”；
- 现代项目（Chrome/Firefox/Safari/Edge ≥ 79）可放心用：
color: var(--text-primary, #333); - 回退值仅对支持
var()但变量未定义的场景生效，不是“降级到旧浏览器”的方案 - 不要在
@keyframes或@media查询条件里用变量——部分旧版Safari会解析失败 - 动画中使用变量需注意性能：频繁修改
--bg-hover可能触发重排，不如用transition: background-color直接控制
--text-primary，而是当设计提出“把主色从蓝色改成青绿色，但保持所有状态色阶关系”时，你能立刻判断哪些变量要改、哪些该保留、哪些其实不该属于这一组。这需要命名一开始就锚定在行为上，而不是视觉上。 
