CSS 格式化器做两件相反的事:把拥挤的单行样式表美化成一目了然的缩进规则,以及把冗长的 CSS 压缩成生产环境下最小的有效形式。粘贴一份样式表,选择方向,两种输出的结果都随时可以复制。前端开发者用它来解读需要覆盖的压缩第三方 CSS、统一团队格式,以及在部署前给样式表再省下几个字节。
压缩比人们想象的要克制得多。它只移除浏览器不需要的字符:
/* ... */。0px 变成 0。它不会改变选择器、属性名、属性值或层叠关系。color: #ff0000 和 color: red 行为相同,但压缩器不会把其中一个转成另一个,因为那会以你并未要求的方式改动源码。经验法则:压缩改变的是表示形式,绝不是含义。
下面是某份基础样式表的一段:
/* Primary button */
.btn {
display: inline-block;
padding: 12px 20px;
border: 1px solid #d1d5db;
border-radius: 6px;
background: #ffffff;
color: #111827;
}
.btn:hover {
background: #f3f4f6;
}
上面这段本来就是可读的;跑一遍压缩后,它会变成去掉注释的单行,字节数大约是原来的三分之一。要看一个真实的例子,可以把某个压缩过的第三方样式表粘贴进来,点「格式化」:每条规则展开到各自的行上,而你想覆盖的那个属性——某个优先级、某个 z-index、某个硬编码的颜色——几秒内就能找到,而不必在文字墙里滚动查找。
margin 会出现在哪里。margin: 0 10px 很紧凑,但隐藏了设置了哪几条边。当意图重要时,优先使用明确的长写法,并跑一遍格式化器来保持一致。+ 和 − 运算符两侧需要空格;一个把 calc() 内所有空白都剥掉的步骤会产生无效 CSS。最后说说格式化在什么时候值得做。对于你自己拥有的样式表,在项目开始时格式化一次,然后让构建步骤在输出时压缩它——这样仓库里保留可读副本,浏览器里是压缩副本。格式化的价值与其说体现在日常流程中,不如说体现在「空白就是障碍」的那些时刻:阅读一个引入的库、审阅别人压缩过的输出,或者在一个作为单行长文件收到的文件里追查某条坏掉的声明。
可以,只要保留原始文件。压缩只移除空白、注释和可选的分号,不会重写选择器或属性值,所以浏览器看到的样式表是等价的。实用法则:把压缩文件当成构建产物——部署它,但绝不去编辑它,因为一个压缩成单行、包含成千上万条规则的样式表几乎无法维护。
压缩输出会去掉注释,这通常正是目的——许可证头、分节标记和说明是给开发者看的,不是给浏览器看的。请把注释留在源文件里。如果许可证要求随文件发布头部声明,就用一个支持保留首条注释的工具单独保留它。
CSS 要求 calc() 中的 + 和 − 运算符两侧必须有空格;省略它们是无效的。因此,一个会规范化空白的格式化器必须保留这些空格,而不能把它们折叠掉。如果你手写 calc(),请记住 calc(100%-20px) 无效,calc(100% - 20px) 可用,而 calc(100%/3) 没问题,因为除法不需要空格。
不能。格式化只是重新排版交给它的文本;它无法修复未闭合的大括号、下一条声明前缺失的分号,或写错的属性名。它能让这些问题更容易被发现,因为每条声明各占一行,但校验和修复仍然是你的工作——请用浏览器检查器或 linter 检查输出。
压缩可能会移除一些 gzip 或 Brotli 所利用的冗余,所以压缩后的体积未必会像工具前后对比数字所显示的那样等量缩小。压缩和再压缩仍需配合使用——两者你都要发布——但合起来的节省通常小于单独看任一个数字时的预期。
不会。格式化和压缩完全在浏览器里用 JavaScript 运行。附着在未发布产品上的样式表、内部品牌设计变量,以及任何你不愿分享的内容,都留在你的设备上。
由 HandyTools Hub 团队审校 · 最后更新