5.3固执与灵活的再平衡

5.3 固执与灵活的再平衡

争论从未停止

Prettier 的"固执"哲学在实践中取得了巨大成功，但关于"哪些地方应该固执、哪些地方应该灵活"的争论从未真正停止。

每当有人在 Prettier 的 GitHub 仓库提一个 feature request 说"希望能配置 XXX"，维护者通常的回复是"No，Prettier 的哲学是不提供这个选项"。这种回复对提 PR 的人来说可能感到沮丧，但对维护者来说，每多一个配置项就意味着维护负担的增加、一致性保证的减弱、以及社区分歧的新来源。

这种"刚性拒绝"的策略有其逻辑基础——如果 Prettier 开始接受各种配置请求，它最终会变成一个"可配置的 ESLint"，失去了"终结争论"的核心价值。但完全不接受任何新配置也不现实——某些场景确实存在合理的需求，强行固执只会把用户推向其他工具。

已有的"妥协"案例

Prettier 确实在少数几个议题上做出了让步，这些案例说明了"固执"和"灵活"之间的实际边界。

singleQuote。这是最初的争论点之一。很多团队强烈偏好单引号，但 Prettier 默认用双引号。维护者最终同意暴露这个选项，理由是"单双引号的差异纯粹是视觉偏好，不影响任何结构决策"。

semi。行尾分号的存废是一个经典争论。Prettier 默认加分号，但很多团队（包括 React 核心团队）选择了无分号风格。维护者同意暴露这个选项。

printWidth。行宽是最直接影响布局效果的参数，它从一开始就是可配置的——Prettier 的维护者认为行宽是一个"结构性参数"而非"风格偏好"，应该让用户控制。

arrowParens。箭头函数单参数是否加括号。这个选项是在社区大量请求后添加的。

这些让步的共同特征是：它们不涉及代码的结构性布局决策，只涉及表面的符号选择。单引号 vs 双引号不影响换行位置，分号 vs 无分号不影响缩进层级。Prettier 把"结构性决策"（哪里换行、怎么缩进）牢牢锁住，只在"表面符号"（用哪种引号、有没有分号）上给出有限的灵活性。

被拒绝的配置请求

与之对比，以下配置请求被明确拒绝，且维护者给出了清晰的拒绝理由：

"能否让对象字面量的属性按字母排序？"——拒绝。Prettier 只管格式，不管代码的逻辑组织。排序属性可能改变代码行为（有些对象属性顺序影响继承或序列化）。

"能否让 import 语句按模块名排序？"——拒绝。同上，import 排序属于代码组织的范畴，不属于格式化。使用 eslint-plugin-import 的 sort-imports 规则来做这件事。

"能否支持自定义缩进风格？"——拒绝。缩进策略是结构性决策，开放配置会导致一致性保证减弱。

"能否让 if 语句的左花括号换到下一行（Allman 风格）？"——拒绝。花括号位置是结构性决策，Prettier 固定为 K&R 风格（同一行）。这是社区中讨论最多、争议最大的拒绝之一。

图 5-3：已接受 vs 被拒绝的配置请求

拒绝的哲学逻辑

Prettier 维护者划分"接受"和"拒绝"的判断标准可以归纳为：

1. 是否影响代码的结构性布局？ 影响换行位置、缩进层级的决策不接受配置。不影响结构的符号选择可以考虑。
2. 是否可能导致行为改变？ 可能改变代码运行时行为的"格式化"不被接受（如属性排序、import 排序）。
3. 是否增加了维护负担？ 每个配置项都需要在所有语言、所有场景中测试，配置越多，测试矩阵越大，维护负担越重。
4. 是否开启了新的争论空间？ 某些配置一旦开放，会引发大量"为什么不能更灵活"的后续请求，形成滑坡效应。

这个标准在大多数情况下运作良好，但确实存在灰色地带。比如 printWidth 本质上也影响结构性布局（它决定了哪里换行），但因为它从一开始就是可配置的，已经成为了 Prettier 哲学的一部分。

社区的两种声音

关于这个议题，社区存在两种立场鲜明的声音。

严格派主张：Prettier 的核心价值就是"不让你选"，任何新的配置项都是对这个价值的侵蚀。如果团队需要更灵活的格式化，应该考虑其他工具，而不是要求 Prettier 变得更"不固执"。

实用派主张：Prettier 的固执应该服务于"终结争论"这个目标，而不是成为教条。当某个配置请求能解决一个普遍存在的、合理的痛点时，拒绝它只会把用户推向工具碎片化（一部分人用 Prettier + 一部分人用其他工具），而不是让所有人在同一个工具下达成统一。

这两种立场都有道理，而且 Prettier 的维护者实际上在这两者之间寻找平衡——不是非黑即白的"要么全部可配置要么完全不可配置"，而是在每个具体请求上判断"接受这个配置是否会显著削弱一致性保证"。

真实项目中的取舍

理论上的边界很清晰，真实项目里却总是混着人情与历史。举一个常见的例子：一个维护了五年的老项目，代码全部是 4 空格缩进、双引号、行尾分号，团队几十人早已习惯。如果团队直接用 Prettier 默认配置（2 空格、双引号、加分号），全仓库会瞬间产生几十万行 diff，代码评审被格式改动淹没。

实际的做法通常是：接受 Prettier 的默认风格，但在引入的那一刻集中提交一次全量格式化（称为"格式重构提交"），之后所有新代码自动统一。这个提交会让 git blame 失效，但现代 git 支持 git blame --ignore-rev 忽略指定提交，可以缓解。

另一个常见摩擦点：团队里经验最老的工程师对代码风格有强烈审美，而新成员只想要一致性。Prettier 的立场天然站在"一致性"这边——这不是针对谁，而是工具的设计目标。如果团队无法接受这个立场，可能需要考虑 Biome 这类可配置性更高的工具，或者干脆接受"格式不完全统一"。

这些取舍没有标准答案，但有一个决策框架可以复用：先问"统一格式带来的收益是什么"（评审更快、diff 更干净、新人上手更快），再问"牺牲的是什么"（个人风格、部分历史 diff），最后看收益是否大于牺牲。大多数情况下答案是肯定的，这也是 Prettier 能成为事实标准的原因。

图 5-4：格式化工具的可配置性光谱

未来的可能走向

一个可能的方向是：Prettier 核心保持严格的固执，但通过更灵活的插件系统让有特殊需求的团队实现定制。这样核心的一致性不受影响，而需要灵活性的团队可以通过插件在有限范围内调整行为。

另一个方向是：Prettier 保持现状，但社区中出现更多像 dprint、Biome 这样的替代工具，它们提供更灵活的配置选项，给开发者更多的选择空间。这种"分化"可能反而是健康的——不同工具定位不同的使用场景，而不是所有工具都试图做同一件事。

无论走向如何，Prettier 确立的一个核心原则——"代码格式化的价值在于一致性而非风格的优劣"——已经成为行业共识。这个共识不会因为具体配置的增减而改变。