fff与#ffffff经gzip压缩后体积一致，现代构建工具（如cssnano）会在压缩阶段自动归一化Hex写法；真正影响CSS体积的是选择器爆炸、嵌套过深和冗余类名。
#fff 比 #ffffff 看似省了3个字符，但对最终打包体积影响几乎为零——gzip 后两者压缩结果完全一致，且现代构建工具（如 PostCSS、cssnano）在压缩阶段会自动做等价转换。真正拖累 CSS 体积的，从来不是手写三位还是六位 Hex。
cssnano 的 mergeLonghand 和 normalizeWhitespace 才管 Hex 缩写
你不用手动把 #aabbcc 改成 #abc，只要 cssnano 开启了默认压缩规则，它就会在解析 AST 后统一归一化：
-
color: #ff0000→color: #f00 -
background: #112233→background: #123 - 但
#123456这种无法简写的，保持原样
关键点在于：这个转换发生在 PostCSS 处理链末尾，必须确保 cssnano 在 autoprefixer 之后运行，否则可能因语法插件提前转义而跳过。
三位 Hex 写法只在 Sass/Less 变量定义时有实际意义
当你在预处理器中大量使用颜色变量，比如：
立即学习“前端免费学习笔记（深入）”；
$primary: #007bff; $primary-light: #e0f0ff;
这时用三位写法能略微降低源码可读体积（尤其在几十个变量的 _variables.scss 里），但注意：
- Sass 编译后仍会输出六位格式，除非你显式用
#{str-slice($primary, 1, 4)}截取 - 更稳妥的做法是交由 cssnano 统一处理，避免人为出错（比如把
#123456错写成#123） - 如果项目用了 CSS Modules + exportLocalsConvention，手写短 Hex 还可能干扰哈希生成逻辑（极小概率）
真正该盯住的体积黑洞：选择器爆炸和未用类
比起纠结 #f00 还是 #ff0000，这些才实打实增加 KB 级体积：
-
@extend %button-base在多处调用，生成.header .btn, .modal .btn, .sidebar .btn这类重复前缀选择器 - 嵌套超过 3 层：比如
.card { .list { .item { color: #f00; } } }，每层都复制父选择器 - Tailwind 类名手写冗余：
class="text-gray-800 bg-white p-4 rounded-lg border border-gray-200"占据 HTML 体积，且无法被 PurgeCSS 安全剔除（尤其含动态拼接） - CSS Modules 下未包裹
:global(.el-button)，导致构建时生成大量无用局部映射对象，塞进 JS bundle
Hex 位数只是表象，压缩链是否完整、源码结构是否收敛、作用域是否受控——这三者才决定 CSS 最终体积的量级。别在 #f00 上花时间，先跑一遍 npm run build -- --stats 看看哪些 CSS 文件占了前五。
