十六进制颜色值大小写不区分，但统一小写可避免git diff冗余、工具链报错及postcss处理异常，提升协作与维护效率。
浏览器完全不关心 #FF0000 还是 #ff0000，两者渲染结果一模一样；但团队协作、工具链和长期维护中，大小写混用会悄悄埋雷。
Git diff 里全是无效变更
当两个人分别提交 #FF6B35 和 #ff6b35，Git 会当成两行不同内容记录。这导致：
- PR 审查时真正改了配色逻辑的提交被淹没在大小写抖动里
- 自动化颜色提取脚本靠正则
/#([a-f0-9]{6}|[a-f0-9]{3})/gi匹配，加i标志虽能兜底，但多一层容错就多一分维护成本 - 某些老旧主题色提取工具硬编码小写正则
/#[a-f0-9]{6}/，遇到大写直接漏掉
stylelint 和构建工具默认报错
stylelint 默认规则 color-hex-case: "lower" 会把 #FF0000 当作警告，CI 流水线不修复就过不了 lint 阶段。而多数压缩器（如 cssnano）不会自动转写大小写，也不会合并 #FF0000 和 #ff0000 —— 它们在压缩后依然并存，白白增加 gzip 重复模式识别负担。
PostCSS 插件可能绕过 normalize 逻辑
像 postcss-color-mod-function 这类插件，在内部 normalize 步骤中默认按小写处理。如果传入 #F0F，它可能跳过转换，导致后续依赖该 normalize 的逻辑（比如主题色导出、暗色模式适配）失效。这不是 bug，是设计预期：小写才是 canonical 形式。
CSS 中真正在意大小写的部分容易被混淆
CSS 里确实有大小写敏感项：div#MyId 和 div#myid 在 strict DOCTYPE 下不等价；--mainColor 和 --maincolor 是两个变量；font-family: "Helvetica Neue" 大小写错一位可能 fallback 到 serif。如果颜色值也混用大小写，新人容易误以为 #FF0000 和 --primary-color: #ff0000 遵循同一套大小写规则——这种认知偏差比多敲几个小写字母更难调试。
统一小写不是为了浏览器，而是为了让工具敢做假设、让 diff 可读、让新人少走弯路。最麻烦的从来不是写错一个 F，而是你改了十处颜色，却只有一处生效，最后发现是某处 #F0F 被 PostCSS 插件静默跳过了 normalize。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
