所有命名颜色（如red、tomato）都不该出现在生产代码中，因其不可维护、不可计算、不响应主题、易拼写错误且无障碍检测失效；应统一用hsl或rgb配合css变量管理，仅transparent和currentcolor例外。
所有命名颜色（如 red、tomato、lightgray）在现代 CSS 工程中都不该被“校验通过”——它们不是过时了才危险，而是从设计上就不该出现在生产代码里。校验报错只是表象，真正的问题是这些值无法维护、不可计算、不响应主题、易拼写失效。
为什么 stylelint-color-no-named 会报错
插件报错不是因为它“太严格”，而是它在拦截真实风险：
-
gray和grey是两个独立关键字，团队混用会导致搜索失效、CI 构建不一致 -
darkslategray这类长名在无障碍检测工具中常被跳过，对比度检查直接漏掉 -
ButtonFace等系统色在 PostCSS 构建阶段可能被静默丢弃，开发者工具里整行变灰但无提示 - 写
color: red;后再改变量--error: #e74c3c;，前者完全不受影响，语义断裂
如何让校验通过且不妥协语义
不是绕过规则，而是用可验证的替代方案落地：
- 统一用
hsl()或rgb()+ 自定义属性，例如：--color-error: hsl(0, 80%, 55%); - 所有颜色变量必须在
:root中显式声明，构建时用css-tree静态校验引用完整性 - 禁用任何字面量颜色值：PostCSS 插件需覆盖
filter: drop-shadow(#000)、border: 1px solid #ccc等隐性硬编码 - 允许的例外只有
transparent和currentColor（注意必须全小写，CurrentColor无效）
开发时怎么快速修复已报错的命名色
别手动替换为十六进制——那只是换了个硬编码形式。要重建语义链：
- 查设计规范，确认该色的实际用途（是错误态？禁用态？装饰高亮？），重命名为
--state-error、--ui-disabled等 - 用 HSL 表达意图：
--state-error: hsl(0, 100%, 50%)比#ff0000更易微调明暗 - 深色模式只需覆盖同一变量：
:root[data-theme="dark"] { --state-error: hsl(0, 90%, 65%); } - 临时调试可用
color: red;，但必须加注释/* DEBUG: remove before merge */，并配置 ESLint 拦截未清除的注释
最难的不是写对 hsl(0, 80%, 55%)，而是当别人 PR 里出现 color: salmon; 时，你得立刻意识到：这不是一个颜色，而是一个即将在高对比度模式下消失的可访问性漏洞，一个下次重构时要翻三遍代码才能定位的语义断点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
