十六进制颜色大小写混用会触发 lint 失败和构建异常，因 stylelint 默认要求小写、postcss 插件仅处理小写格式、cssnano 无法合并不同大小写的重复值，导致 ci 失败、颜色转换失效和体积增大。
十六进制颜色混用（#FF0000 和 #ff0000）、硬编码（#4a90e2）、RGB 与 HSL 并存，不是“写不出来”，而是让每次改色都变成一次风险操作——你改的不是颜色，是在猜上下文。
为什么大小写混用会触发 lint 失败和构建异常
CSS 工具链对大小写敏感，但浏览器不敏感，这造成开发与构建环境的认知割裂：
-
stylelint默认启用color-hex-case: "lower"，遇到#FF6B35就报 warning，不修复过不了 CI - 某些 PostCSS 插件（如
postcss-color-mod-function）在 normalize 阶段只处理小写格式，大写值可能绕过转换逻辑，导致color-mod()生效失败 -
cssnano不自动统一大小写，#FF0000和#ff0000被视为两个不同字符串，gzip 压缩时无法合并重复模式，白白增加体积
为什么硬编码 Hex 值让“调亮一点”变成玄学操作
#4a90e2 这类值没有色彩语义，人眼无法判断哪一位控制明暗、哪一位影响色相：
- 想让按钮悬停变浅：有人调最后两位
e2 → f2，结果偏青；有人压前两位4a → 3a，又容易发灰 - RGB 是设备模型，不是人眼模型；而
hsl(210, 70%, 60%)中只改60%就能稳定提亮，色相和饱和度锁死，整套色系不会跑调 - 深色模式适配时，
#4a90e2没法自动推导对应暗色值，必须人工查表或试错；而hsl(var(--brand-h), var(--brand-s), calc(100% - var(--brand-l)))可直接复用逻辑
为什么全局搜索替换 Hex 值不可靠
Hex 值本身不携带业务含义，同一颜色在不同上下文中可能有不同意图：
-
#e74c3c在 A 文件里是“删除按钮背景”，在 B 文件里是“表单错误边框”，全局搜#e74c3c替换，可能误伤非目标用途 - Git diff 显示为多处散点变更，而非一次语义化更新，Code Review 时难以聚焦真实意图
- 自动化工具（如主题提取脚本）依赖正则匹配，但
#e74c3c、#E74C3C、rgb(231, 76, 60)三种写法需分别覆盖，漏一个就断链
真正难的不是“怎么写出合法颜色”，而是“改的时候怎么确保所有相关上下文都被正确识别、一致更新、不引入偏色”。Hex 格式越自由，维护时越需要人工校验——而人工永远是最不可靠的环节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
