命名颜色仅在原型、教学或原子类（如.text-red）中提升可读性，因其缺乏语义区分能力，无法表达错误提示色或按钮悬停色等具体意图；系统级命名颜色（如ButtonText）跨平台表现不稳定且不可控，应仅作fallback；命名颜色与CSS变量需分层使用——前者用于文档示例或原子类速写，后者承载可维护、可计算、可主题化的语义。
命名颜色在什么场景下真正提升可读性
直接写 red 或 blue 只在原型、教学或极简工具类（如 .text-red）中成立；它不适用于组件级样式，因为 red 没法表达“这是错误提示色还是主按钮悬停色”。真正提升可读性的前提是：命名颜色被约束在明确的语义上下文中，比如 .btn-error 用 red，.status-success 用 green，而不是全局替换所有 #dc2626 为 red。
系统级命名颜色（如 ButtonText）为什么慎用
这类颜色会随操作系统主题动态变化，但跨平台表现不稳定：ButtonFace 在 Windows 上是浅灰，在 macOS 上可能偏白，Linux 下甚至不可靠。更关键的是，它们无法参与 CSS 变量计算、不能被 PostCSS 插件校验、也不支持深色模式精细控制。实际项目中，除非你在开发系统级工具（如浏览器插件 UI），否则建议只把它们当作 fallback 值，例如：
.button {
background-color: var(--myapp-btn-bg, ButtonFace);
}
常见错误现象：color: Highlight; 在 Safari 中失效、在 Chrome 中高亮区域过宽，且无法用 JS 读取其计算值做逻辑判断。
命名颜色和 CSS 变量怎么共存不冲突
别把 red 当变量值用，而是用它辅助语义化类名。比如定义 --myapp-color-error: red; 是错的——这会让变量失去可维护性；正确做法是让变量保持抽象语义，命名颜色仅用于原子类或文档示例：
立即学习“前端免费学习笔记（深入）”；
-
--myapp-color-text-error的值设为#dc2626，而非red - 原子类
.text-error内部可以写color: red;，因为它本就是“错误文本”这个角色的快捷入口 - 设计系统文档里用
red展示效果，但代码中所有组件都引用--myapp-color-text-error
这样既保留命名颜色的速写优势，又不牺牲主题切换和 CI 校验能力。
BEM 类名里该不该出现命名颜色
不该。像 card--red 或 header__logo--blue 违反 BEM 修饰符原则：它描述外观而非状态。一旦设计改用紫色主色，你得批量重命名、改 HTML、同步 JS 切换逻辑——成本远高于改一个变量值。正确方式是：
- 修饰符只表达意图，如
card--featured、header__logo--inverted - 颜色由语义变量驱动：
card--featured { background-color: var(--myapp-color-surface-featured); } - 如果真要快速调试，用开发者工具临时覆盖，而不是把
red写进类名
最易被忽略的一点：命名颜色的语义是“人类直觉”，而 CSS 变量的语义是“机器可解析”。协作时，前者靠文档对齐，后者靠 lint 规则和 IDE 补全——两者必须分层使用，不能混在同一抽象层。
