Prettier与js-beautify在JavaScript格式化上的对比

在前端与 Node.js 社区的日常开发中，代码格式化直接决定了团队协作的顺畅度与代码审查的专注度。面对 JavaScript 格式化工具的选择，Prettier 与 js-beautify 代表了两种截然不同的架构路线与工程哲学：Prettier 主打“强主观约束（Opinionated）”，通过将代码解析为抽象语法树（AST）后全量重写排版，消灭关于样式的争论；而 js-beautify 则是老牌的“高度可定制美化器”，立足于词法分析与正则修补，尽最大可能尊重开发者原始的代码折行与排布。本文将从底层工作原理、代码输出效果、配置哲学、工程化整合等核心维度展开详细对比，并给出明确的选型决策参考。

一、底层原理与工作架构差异

许多开发者在初次接触这两款工具时，往往认为它们只是内置了不同的缩进与分号规则。实际上，两者在处理同一段 JavaScript 代码时，底层经历的转换机制存在质的差别。

Prettier 并不在乎源码中原有的空格数量、逗号距离或开发者随意添加的手工换行。在处理代码时，Prettier 会先借助 Babel 等语法解析器将源码完整解析为抽象语法树（AST），提取出代码的语法语义。紧接着，Prettier 会彻底抛弃原有的空格、缩进和绝大部分换行符，仅保留注释与 AST 结构，然后依照预设的打印宽度（Print Width）算法，自上而下重新计算每一行代码的最优排列。这意味着，无论原始代码多么杂乱无章，只要其语法结构相同，经过 Prettier 格式化后的输出都是唯一且绝对一致的。

js-beautify 的实现机制则更为轻量与就近。它基于词法分词器（Lexer）将源码切分为 Token 序列，并通过状态机和模式匹配规则对 Token 之间的相对位置进行微调。例如遇到大括号、运算符或关键字时，根据配置参数插入或移除指定数量的空白符。关键在于，js-beautify 默认会尽量保留源码中原有的断行习惯（如 preserve_newlines 选项）。如果开发者在某个长表达式中间随意按下回车，js-beautify 通常会顺从这种排版，仅修正缩进，而不会强行将表达式拉回到单行或按统一规则重新分层折行。

图1：Prettier 全量 AST 重构与 js-beautify Token 流增量美化的原理差异

二、实际格式化场景效果对比

底层原理的差异直接映射在最终的代码排版结果上。下面通过三个极具代表性的场景，直观观察两者的输出差异。

1. 超长函数调用与参数折行

当一段函数调用传入多个长参数、回调函数或解构对象时，代码极易超出常规屏幕宽度。假设有如下原始代码：

// 原始输入代码
function handleUserData(userId, { name, role, permissions = [] }, callback, options) {
  return service.query(userId, "FETCH_RECORD", { deep: true, trace: options.traceId }).then(res => callback(null, res)).catch(err => callback(err));
}

Prettier 的处理：Prettier 检测到单行字符超过了 printWidth（通常设为 80 或 100），会立即触发算法将其分解为多行，严格对齐解构参数与链式调用，闭合括号与分号均被安放在精确的位置：

// Prettier 输出
function handleUserData(
  userId,
  { name, role, permissions = [] },
  callback,
  options
) {
  return service
    .query(userId, "FETCH_RECORD", { deep: true, trace: options.traceId })
    .then((res) => callback(null, res))
    .catch((err) => callback(err));
}

js-beautify 的处理：如果配置了 wrap_line_length，js-beautify 会尝试寻找断点进行折行；但如果配置保持默认或折行阈值未触发，js-beautify 往往只负责把函数内部的缩进补齐，原代码在一行写完的链式调用依然留在单行，无法自动重塑为清晰的分层调用结构。

2. 多余空行与注释锚定

开发者在编写代码时经常随意留下 3 到 5 个空行，或者将单行注释放置在参数声明之间。对于空行，Prettier 拥有一条刚性规则：在任意位置，连续的空行最多只能保留 1 个，多余的空行全部被删除。而 js-beautify 默认会根据 max_preserve_newlines 的设置进行保留，允许代码中存在较大块的空白区域。

对于注释，Prettier 会根据 AST 将注释锚定在对应的语句或节点上，无论怎么格式化，注释都不会与被解释的表达式错位；而基于 Token 的 js-beautify 在面对复杂的换行内联注释时，偶发会出现注释后紧随的代码被错误缩进的情况。

图2：格式化工具的标准处理阶段与排版裁决流向

三、配置哲学：约束与自由的博弈

在配置选项的数量与设计思路上，Prettier 与 js-beautify 形成了鲜明的对比。

Prettier 的“克制哲学”：Prettier 的设计宗旨是消除代码审查中的无谓争执。它刻意将配置选项缩减到极小集合（官方核心配置仅 20 个左右，常用的甚至不足 8 个）。Prettier 官方明确拒绝新增诸如“是否在大括号前后加空格”、“函数名与括号之间是否空一格”等微观样式开关。团队引入 Prettier 之后，所有人只要统一 printWidth、tabWidth、singleQuote 和 semi 等少数几项，就再也不需要在 Pull Request 中讨论格式问题。

js-beautify 的“精细定制”：js-beautify 拥有极为庞大的配置体系，涵盖了数十甚至上百个细粒度选项。开发者可以针对 brace_style（大括号风格，如 collapse, expand, end-expand）、space_before_conditional（if 后是否加空格）、indent_empty_lines（空行是否保留缩进）等进行极为细致的调优。如果某个企业或老旧项目有非常严苛的内部编码规范，且要求工具必须迁就现有风格，js-beautify 几乎总能通过组合参数来满足。

四、工程化集成与团队协同工作流

在现代前端工程中，格式化工具几乎从不孤立存在，而是与 Linter（如 ESLint）、Git Hooks 以及持续集成（CI）紧密结合。Prettier 和 js-beautify 在工程化链路上的角色定位有着明显分野。

目前前端工程的标准解法是“格式归 Prettier，质量归 ESLint”。由于 ESLint 本身也具备一定的格式修复功能（如 eslint --fix），早年容易与格式化工具产生冲突。社区针对 Prettier 推出了 eslint-config-prettier，能够一键关闭 ESLint 中所有与代码格式相关的规则，仅保留语法错误检测、未定义变量排查、Hooks 规则校验等代码质量能力，排版工作则 100% 委托给 Prettier。而在 Git 提交前，通过 lint-staged 仅针对暂存区变更文件执行格式化，大幅提升速度。

相比之下，js-beautify 与 ESLint 的规则对齐成本较高。由于 js-beautify 配置项极多，稍有不慎就会与 ESLint 的某条格式规则产生对抗，导致“代码保存后被 beautify 修改，提交时被 eslint 报错拦截”的尴尬循环。

图3：Prettier 与 ESLint、Git Hook、CI 流水线的工程化协同架构

五、实际配置与执行落地步骤

在实际项目中配置这两款工具时，操作路径均非常清晰直观。以下列出主流场景下的配置文件与命令写法。

1. Prettier 的安装与标准化配置

在项目根目录下通过 npm 安装 Prettier 及 ESLint 冲突解决配置：

# 安装 Prettier 及相关插件
npm install --save-dev prettier eslint-config-prettier

在项目根目录创建 .prettierrc.json 配置文件。在绝大多数团队中，只需指定以下基础规则：

{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "quoteProps": "as-needed",
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "lf"
}

并在 package.json 中添加便捷脚本：

"scripts": {
  "format": "prettier --write \"src/**/*.{js,jsx,ts,tsx,json,css,md}\"",
  "format:check": "prettier --check \"src/**/*.{js,jsx,ts,tsx}\""
}

2. js-beautify 的安装与细粒度配置

若维护遗留项目或希望构建自定义轻量格式化脚本，可单独引入 js-beautify：

# 全局或本地安装 js-beautify
npm install --save-dev js-beautify

在根目录创建 .jsbeautifyrc 配置文件，展现其极高的细节控制力：

{
  "indent_size": 2,
  "indent_char": " ",
  "max_preserve_newlines": 2,
  "preserve_newlines": true,
  "keep_array_indentation": false,
  "break_chained_methods": false,
  "indent_scripts": "normal",
  "brace_style": "collapse,preserve-inline",
  "space_before_conditional": true,
  "unescape_strings": false,
  "jslint_happy": false,
  "end_with_newline": true,
  "wrap_line_length": 100,
  "comma_first": false
}

通过命令行对指定文件执行格式化：

# 替换目标文件中的代码格式
npx js-beautify -r src/legacy-app.js

六、选型决策指南与总结

在明确了原理、表现和配置哲学的差异之后，技术选型就不再是主观喜好的较量，而是基于项目生命周期与团队协作诉求的理性选择：

• 强烈推荐 Prettier 的场景：
  1. 多人协作团队与开源项目：必须保证所有成员提交的代码格式绝对统一，拒绝在 Code Review 中耗费哪怕一分钟去纠结大括号和换行位置。
  2. 现代前端框架全家桶：项目包含 React (JSX)、TypeScript、Vue SFC 或 Tailwind CSS，Prettier 的官方插件和解析生态提供了无可比拟的稳定性。
  3. 标准化 CI/CD 流程：需要借助 prettier --check 作为强效门禁拦截不合规提交。
• 适合选择 js-beautify 的场景：
  1. 维护大型遗留系统：老旧项目经过多年迭代，已有特定的排版习惯；全量运行 Prettier 会产生极其庞大的 Git Diff，导致 git blame 追溯历史困难，此时 js-beautify 能够按需做最小改动。
  2. 对代码排版有极其严苛的特定格式要求：比如必须保留特定的矩阵多行排列表格、特殊的大括号对齐方式，而 Prettier 无法通过配置妥协。
  3. 轻量级后端/离线自动化脚本：无需复杂的 AST 生态依赖，只需要极轻量、快速地给某段拼接出来的 JS/HTML 字符串做基础缩进。

图4：不同业务诉求下的格式化工具决策导图

综上所述，Prettier 与 js-beautify 并非简单的“新旧替代”关系，而是代表了两种不同的工程理念。在当今快节奏、重协作的现代前端体系下，Prettier 凭借 AST 全量重构与强主观约定，成为了绝大多数团队的基石工具；而 js-beautify 则凭借精细的自由度与对原始代码的尊重，在老旧工程维护与特定高度定制场景中依然保有一席之地。