CSS 格式化

CSS 格式化做的是一件“为人服务”的事情：把压缩过的、内联的或写得很随意的样式表，重新整理成带缩进、分行清晰的版本。它不会改变样式表的语义，只会改变这份样式在屏幕上呈现的形状。在审查代码、排查覆盖、向同事讲解层叠规则时，可读的版本远比一行流的版本更有用。

为什么格式化值得作为一个独立步骤

CSS 设计上对错误非常宽容：解析器会默默跳过它看不懂的声明，也会让后写的规则悄悄覆盖先写的规则。这种容忍度对浏览器有好处，对人却是个负担。一旦排版被压平，你几乎不可能一眼看出哪条规则被覆盖、哪个媒体查询的作用域写错、哪两个选择器其实命中了同一组元素。格式化把这些结构重新暴露出来，让审查从“逐字读”变成“扫一遍就行”。

格式化会改写什么，又必须保留什么

格式化只应该动那些“只对人有意义”的部分：缩进、换行、花括号四周的空格、注释相对位置。它绝不应该改变同一条规则里声明的先后顺序，不应该改写字符串内容、`url()` 路径、选择器拼写、自定义属性名，也不应该静悄悄删掉 `!important`。任何会让层叠结果发生变化的改动，都不属于格式化的范畴。

• 声明块按统一缩进展开，常见为 2 或 4 个空格，与项目里其它文件的风格保持一致。
• 每条声明独占一行：这样 git diff 里一行变更就对应一个属性变化，审查时不需要左右移动光标。
• 选择器列表按逗号换行：增删一个选择器只会引起一行 diff，回滚和评审都会更轻松。
• 顶层规则之间、@规则边界处保留空行，让样式表“呼吸”起来，这是浏览体验的关键。
• 声明顺序、注释内容、字符串字面量、`url()` 路径都按原样保留，一个字符也不改。

格式化不是“自动修复”。一个合格的格式化器不会删掉它觉得没用的规则、不会顺手把颜色简写、不会调整声明顺序。这些动作属于 Lint 或者构建期优化，应该以独立工具单独执行。

如何使用这个工具

1. 先在 CSS 格式化 中准备一份有代表性的需要更适合审查布局的 CSS 片段和样式块，不要一开始就处理最大或最敏感的真实内容。
2. 执行处理流程并生成更便于评审、对比和讨论的格式化 CSS 结果后，优先检查类嵌套写法、媒体查询、自定义属性、注释，以及输出是否仍表达预期层叠关系，再判断结果是否真的可用。
3. 只有当结果已经适合用于代码审查、片段清理、设计交接和文档准备，并且不再触发这条风险提醒时，才复制或下载输出：格式化提升的是可读性；只要样式行为本身重要，仍应回到真实浏览器里验证。

CSS 格式化 示例

这个 CSS 格式化 示例使用有代表性的需要更适合审查布局的 CSS 片段和样式块，展示生成后的更便于评审、对比和讨论的格式化 CSS 结果，便于你先确认类嵌套写法、媒体查询、自定义属性、注释，以及输出是否仍表达预期层叠关系，再把同样设置用于真实输入。

示例输入

.button { color: white; background: #2563eb; }

预期输出

.button{color:white;background:#2563eb}

把紧凑写法重新展开成易审查的版本

/* 格式化前：从构建产物里复制出来的样子 */
.card{padding:16px;border-radius:8px;background:#fff;box-shadow:0 1px 2px rgba(0,0,0,.06)}.card>.title{font-size:18px;font-weight:600;color:#0f172a}.card>.body{margin-top:8px;color:#475569}

/* 格式化后：适合审查和做 diff 的样子 */
.card {
  padding: 16px;
  border-radius: 8px;
  background: #fff;
  box-shadow: 0 1px 2px rgba(0, 0, 0, 0.06);
}

.card > .title {
  font-size: 18px;
  font-weight: 600;
  color: #0f172a;
}

.card > .body {
  margin-top: 8px;
  color: #475569;
}

格式化最能节省时间的场景

格式化的收益，在“同一份样式表会被多人、多次阅读或对比”时最为明显。以下是几个最常见、收益最直接的场景。

• 审查从构建产物里复制出来的样式片段，手头没有源码时尤其需要先格式化再读。
• 整理从富文本编辑器或 CMS 里粘出来的样式，原始结果通常都是一行流加随机空格。
• 审阅社区分享的片段、或设计师交付的样式草稿，先格式化再决定是否合并到项目规范里。
• 为 Pull Request 做出可读的 diff：格式化后，一个属性的变更只会引起一行 diff，而不是整段重排。
• 在培训、文档或写教程时讲解某段样式逻辑，缩进让层叠关系直接“看出来”，比口头解释高效得多。

格式化无法替你解决的问题

格式化能让结构变得可见，但它本身并不能证明这份样式表是正确、性能良好或易维护的。下面这些问题，乍一看像是“没格式化”造成的，其实需要交给其它工具来解决。

• 特异性冲突：两条都格式整齐的规则仍然可能在层叠中互相覆盖。格式化能把它们摆在一起，但不会替你决定谁应该胜出。
• 死代码：格式化器看不到 HTML 和 JS 上下文，因此不知道哪个选择器在页面上真的命中了元素。这件事要交给 PurgeCSS 这类工具，并配合测试用例一起跑。
• 风格规范违规：例如要求 `border-radius` 始终写在 `background` 之前，这是一项团队约定，应该由 stylelint 这类专门的 Lint 工具来强制执行，而不是依赖格式化器。
• 传输体积：格式化后的样式总比压缩版更大。在审查和源码仓库里使用格式化版本；最终交付给浏览器的还是压缩版本。

格式化与容易混淆的相邻步骤

使用注意

• 复用更便于评审、对比和讨论的格式化 CSS 结果前，先检查类嵌套写法、媒体查询、自定义属性、注释，以及输出是否仍表达预期层叠关系。
• 格式化提升的是可读性；只要样式行为本身重要，仍应回到真实浏览器里验证。
• 当结果会影响生产工作或客户可见内容时，应保留原始需要更适合审查布局的 CSS 片段和样式块以便回退和核对。

CSS 格式化 参考说明

CSS 格式化 的参考说明应始终围绕需要更适合审查布局的 CSS 片段和样式块、生成的更便于评审、对比和讨论的格式化 CSS 结果，以及用于代码审查、片段清理、设计交接和文档准备前必须确认的检查点。

• 输入重点：需要更适合审查布局的 CSS 片段和样式块。
• 输出重点：更便于评审、对比和讨论的格式化 CSS 结果。
• 复核重点：类嵌套写法、媒体查询、自定义属性、注释，以及输出是否仍表达预期层叠关系。

参考资料

• W3C CSS Syntax Module Level 3
• MDN: CSS