CSS 中应避免使用英文颜色名，因其难检索、难替换、拼写不一致、无法语义化、跨浏览器兼容性差、阻碍设计系统落地，且增加维护成本。
颜色英文名在 CSS 中难检索、难替换
项目里写 color: red; 看似简单，但当你要把所有“红色系”统一改成品牌主色 #e53935 时，red、orange、tomato、lightcoral 这些英文名散落在几十个文件里，根本没法用 IDE 的「全局替换」精准命中——它们不是语义关键词，而是孤立的字面值。
- IDE 搜索
red会误中变量名、类名、注释甚至 URL 中的字符串 -
darkblue和navy实际是同一色值，但无法被归为一类处理 - 团队协作时，有人写
grey，有人写gray（CSS 标准两者都支持，但拼写不一致）
CSS 自定义属性 + 英文名混合导致命名失控
一旦项目引入了 CSS 自定义属性做主题管理，比如 --primary-color: #2196f3;，再混用英文名就会让逻辑断裂。下面这种写法很常见，但维护成本极高：
:root {
--primary: blue;
--warning: orange;
--error: red;
}
<p>.button--error {
background-color: red; /<em> ❌ 这里没用变量，和 --error 脱节 </em>/
}- 样式规则和变量定义失去绑定，改
--error不会影响已写的red - 设计师给的色值更新后，你得手动翻遍所有
red/orange找出哪些该换、哪些是装饰性临时色 - 英文名无法表达层级，比如
--text-primary和--text-secondary是明确的抽象，而black和grey只是视觉描述，无法反映用途
不同浏览器对英文名的支持存在细微差异
CSS 颜色英文名共 140+ 个，但并非所有都跨浏览器稳定。例如 rebeccapurple 是后来加入的，IE 完全不支持；darkslategray 在旧版 Safari 中曾有渲染偏差；更隐蔽的是大小写问题：Transparent（首字母大写）在部分 Android WebView 中被当作无效值，而 transparent 始终有效。
-
honeydew、mintcream这类低频名，在代码审查或压缩工具中可能被误删（如某些 CSS minifier 会把未知颜色名当作冗余） - CI 构建时若用不同版本的 PostCSS 或 Sass，对
aliceblue等名字的解析容错性不一致 - 无障碍工具或颜色对比度检测插件，通常只识别十六进制、RGB、HSL，遇到
firebrick可能跳过校验
设计系统落地时，英文名无法承载语义约束
真正需要控制颜色使用的地方，不是“能不能用”，而是“该不该用”。比如按钮禁用态必须用 --disabled-bg，不能直接写 lightgray——因为后者不带状态语义，也无法通过 CSS 作用域自动继承主题变体（如深色模式下 --disabled-bg 可映射为 #424242，而 lightgray 固定是 #d3d3d3）。
立即学习“前端免费学习笔记（深入）”；
- 设计规范文档里写“主按钮背景色：#2196f3”，而不是“主按钮背景色：blue”——开发照着文档实现时，复制十六进制最可靠
- UI 组件库的 Storybook 示例若用英文名，开发者复制过去就断开了和主题系统的连接
- 颜色 Token（如
color-surface-default）必须指向确定色值，英文名无法参与 token 解析链
项目里颜色值越早收敛到变量或设计 Token，后期改色、切主题、做 a11y 检查就越省力。英文名适合原型草稿或单页小 Demo，一旦进入协作开发阶段，它就成了隐性技术债。
