命名颜色仅适用于原型或极简场景，正式项目应禁用除transparent和currentcolor外的所有命名色，统一使用语义化css变量以保障可维护性、无障碍合规与主题一致性。
color: red 这类命名颜色写起来快，但实际项目里容易失控——不是所有“red”都该是同一个红，也不是所有组件都能直接用 blue 而不破坏语义。真要用好命名颜色，得先分清它适合在哪、不适合在哪。
命名颜色只适用于原型或极简场景
命名颜色（如 red、darkslategray）本质是 CSS 内置的 140 个固定值，它们没有业务含义，也不受项目主题约束。
常见误用：在按钮样式里写 color: green 表示“成功”，结果设计稿换成了青绿色系，全量替换成本高且易漏。
适用场景：
• 快速验证布局，比如临时加 border: 2px solid orange 框出某个区域
• 极小静态页（单页简历、个人介绍），无主题切换需求
• CSS 重置或 debug 工具类（如 .debug-bg-red { background-color: red; }）
命名颜色和自定义变量混用会破坏一致性
一旦项目引入了 CSS 自定义属性（比如 --primary-color: #3b82f6），再夹杂 color: steelblue 就等于开了两个颜色管理入口。
问题表现：
• 设计系统升级主色时，漏掉所有散落的 teal、coral 等命名色
• 暗色模式下，lightgray 在深背景上几乎不可见，而 var(--text-muted) 可统一响应
• Linter（如 stylelint）无法校验命名色是否符合对比度标准，但能检查 var(--text-primary) 是否被正确定义
建议做法：
• 全局禁用命名颜色（除 transparent 和 currentColor 这两个有明确语义的）
• 把 red 这类词只保留在文档注释或调试临时代码中，不进正式 commit
• 若必须保留，统一映射到变量：:root { --error: red; }，后续只用 color: var(--error)
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
命名颜色在无障碍和对比度检测中不可控
WCAG 要求文本与背景对比度 ≥ 4.5:1，但 firebrick 在白底上对比度约 3.9:1，lightcoral 更只有 2.3:1——这些值不会报错，但会通不过自动化检测工具（如 axe、Lighthouse）。
更麻烦的是：
• 不同浏览器对同一命名色的渲染略有差异（尤其旧版 IE 对 rebeccapurple 的处理）
• 屏幕色域差异会让 olive 在某些设备上接近灰褐色，失去“橄榄绿”的识别感
• 无法通过 hsl() 或 color-mix() 动态调整亮度，比如让所有文字色自动变深以适配暗色模式
务实做法：
• 用 WebAIM Contrast Checker 测试每组实际使用的颜色组合，而非依赖命名色名头
• 把命名色当作“已知风险值”单独归档，例如在 design-tokens.json 中标注 "firebrick": {"wcag-ok": false, "use-case": "border-only"}
• 所有正式文本色必须来自 var(--text-*) 变量体系，并确保其值满足 color-contrast() 函数的最低阈值
blue”，而是“用了之后谁来保证它在所有上下文里都可读、可维护、可测试”。命名颜色像一把没刻度的尺子——短时间省事，长期要花三倍力气去校准。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
