引用：A Prettier JavaScript Formatter
这篇老文章讲了一件现在看依然很锋利的事：代码格式问题，不该继续靠团队吵出来，而应该直接交给工具结束争论。
原文要点
- Prettier 的核心主张是减少可配置项，用统一格式约束直接终止团队风格争论。
- 它通过语法结构重打印而非保留原排版，强调结构一致性优先于个人偏好。
- 文章把格式化定位为协作效率问题，而不仅是审美问题。
我的判断
我一直觉得，Prettier 真正改变前端世界的地方，不是它把分号、换行、缩进排得多漂亮，而是它干脆把“格式到底该怎么定”这件事，从团队协作里整个拿掉了。
这听上去很简单，实际一点都不简单。因为大部分工具的本能，都是尽量满足用户，给你更多开关，更多细粒度选项，最好每个人都能调到自己满意。Prettier 偏不。它的核心态度近乎粗暴：你别再纠结这些了，我来定，而且我尽量不给你更多可争的空间。
这套做法第一次看会让人不舒服。尤其是写代码的人，本来就天然有一点“排版主权”的执念，总觉得自己的换行更有呼吸感，自己的空格更体现结构，自己的链式调用写法更优雅。Prettier 最不留情面的地方就在这，它先把你的原始格式全部丢掉，再根据 AST，也就是抽象语法树，重新打印一遍。换句话说，它根本不尊重你的排版历史，它只尊重代码结构本身。
但我越来越觉得，这种“不尊重”，反而是一种更成熟的尊重。它尊重的不是个人偏好，而是团队注意力。很多工程团队表面上在讨论规范，实际上是在把精力浪费在极低价值的细枝末节上。tab 还是 space，尾逗号要不要，长链式调用到底断在哪一层，这些问题最可怕的地方不是难，而是它们极易制造一种“我们正在认真做工程”的幻觉。其实没有，你们只是在争装修风格。
James Long 当年写那篇文章时提到一个关键点，我很认同：最大行宽不是附属规则，而是排版系统的核心约束。只要你承认代码必须在有限宽度里阅读，你就不可能再靠零散 lint rule，也就是零散的静态检查规则，拼出稳定的格式系统。这也是为什么 ESLint 一直能“检查风格”，却很难真正结束风格战争。它更像交警，能指出这里超速、那里违停，但它不会帮你重建整座城市的道路系统。Prettier 则不一样，它直接重画道路。
所以我对 Prettier 的判断是，它其实不是 formatter，也就是自动格式化工具，而是一种组织治理工具。它解决的不是代码美观问题，而是协作中的微型内耗问题。一个团队一旦采用它，效果通常不是“代码更漂亮了”，而是 code review，也就是代码评审，里那些毫无营养的来回明显变少了。大家终于可以把注意力重新放回命名、边界、抽象和逻辑这些真正值得吵的地方。
这也是为什么我觉得 Biome 的崛起很有意思。很多人把 Biome 理解成“更快的 ESLint + Prettier 套餐替代品”，这说法没错，但太浅了。根据 Biome 官方 formatter 文档，它明确承认自己延续了 Prettier 式的 option philosophy，也就是“少给选项，避免风格争论继续转化成配置争论”。所以在我看来，Biome 真正继承的，不只是 Prettier 的格式能力，而是它背后的那套哲学，把工具链从三四个拼装件收回成一个统一入口。它让人看到，前端工具链过去那种“一个问题配一个工具，再加两个胶水包防它们打架”的时代，可能确实该收尾了。
当然，这条路也不是没有代价。Prettier 和 Biome 这类“有观点”的工具，本质上都在拿局部自由换整体秩序。如果你的项目有很多遗留格式约束，或者你就是处在一个必须精细兼容各种历史包袱的环境里，那么这种强统一不一定舒服。工具越强势，你越需要接受一件事：不是所有个人习惯都值得被保存。
但说实话，这恰恰是我欣赏它们的地方。今天的软件世界已经有太多“为了灵活而灵活”的设计了。最后得到的不是自由，而是无穷无尽的配置、迁移、解释成本。Prettier 当年最硬的一刀，就是拒绝把格式化器做成审美投票器。Biome 现在继续沿着这条线往前走，我觉得是对的。
如果一件事既重复、又主观、还特别容易让团队分心，那么在大多数团队协作场景里，它就不该继续被当成人类讨论议题。格式化通常正是这种事。
我的结论很简单：这篇文章值得读，而且不只是给前端工程师读。它真正讲的是一个更普遍的判断，在不涉及特殊约束时，低价值争论就应该尽早交给系统结束。工具最好的时候，不是让你拥有更多选择，而是替你消灭那些根本不值得拥有的选择。
保留意见
统一格式并不等于统一工程质量。格式化器可以减少争论，但无法替代架构决策、命名质量和模块边界设计；把格式化收益夸大成“工程治理万能药”会造成新的误判。