VS Code插件观察 | Prettier:代码格式的“隐形雕刻师”

在早期前端与全栈开发中，代码格式往往依赖开发者个人习惯或团队口头约定，导致合并冲突频繁、Code Review 精力分散。Prettier 的出现并非为了提供另一种“可配置”的格式方案，而是以“有主见的格式化器（Opinionated Code Formatter）”为设计哲学，通过强制统一的排版规则，将格式争议从工程协作中剥离。其 VS Code 插件作为该工具在编辑器侧的入口，已成为现代 Web 开发工作流中不可或缺的基础设施。

一、 发展历程

二、 功能特色与技术设计

1. AST 驱动的排版机制

与基于正则或行尾替换的格式化工具不同，Prettier 首先将源码解析为抽象语法树（AST），在树结构上应用排版规则（如缩进、换行、括号位置、引号风格），最后将 AST 重新打印为字符串。该机制确保：

• 语义完整性：不会因格式修改破坏代码逻辑；
• 注释保留：支持行内、块级、尾随注释的精准锚定；
• 确定性输出：相同输入始终生成相同格式，与操作系统、换行符、编辑器状态无关。

2. “有主见”的配置策略

Prettier 刻意限制可选项，仅提供 printWidth、tabWidth、singleQuote、semi 等十余项基础配置。这种设计并非限制灵活性，而是通过降低配置熵值，避免团队陷入“格式参数谈判”。项目级 .prettierrc 与 .prettierignore 支持层级覆盖，保证仓库内格式一致性。

3. VS Code 插件的工程适配

插件本身不实现格式化逻辑，而是作为 Prettier CLI 的编辑器代理：

• 实现 VS Code 的 DocumentFormattingEditProvider 接口，提供全量与范围格式化；
• 自动探测项目依赖中的 prettier 版本，优先使用本地依赖而非全局版本，避免环境差异；
• 支持配置热重载：修改 .prettierrc 后无需重启编辑器即可生效；
• 与 editor.formatOnSave、editor.defaultFormatter 无缝对接，支持多语言按需分配格式化器。

三、 与现代工程链的协同

1. 与 ESLint 的分工

历史上，ESLint 曾同时承担代码质量检查与格式修正，导致规则冲突与维护成本上升。当前主流实践已明确：

• Prettier 负责格式：处理空格、换行、引号、括号等纯排版问题；
• ESLint 负责语义：检查未使用变量、潜在错误、最佳实践等；
• 通过 eslint-config-prettier 关闭 ESLint 中与 Prettier 重叠的格式规则，配合 prettier-eslint 或 VS Code 的 editor.codeActionsOnSave 实现保存时串行执行。

2. CI/CD 与版本控制集成

VS Code 插件仅作用于开发阶段，生产与协作环节通常通过以下方式固化格式：

• 使用 prettier --check 在 CI 中阻断格式不一致的提交；
• 结合 husky 与 lint-staged，在 pre-commit 阶段仅格式化暂存文件，降低全量扫描开销；
• 将 .prettierrc 与插件配置纳入版本控制，确保新成员拉取仓库后开箱即用。

四、 写在最后

Prettier 的 VS Code 插件并非“格式优化器”，而是工程协作的“降噪器”。它通过 AST 重打印、确定性输出与极简配置，将开发者从缩进争议、换行对齐与合并冲突中解放出来，使 Code Review 的注意力回归逻辑与架构。在工具链日益复杂的今天，Prettier 的价值恰恰在于其克制：不追求万能，只做一件事，并将其做到可预期、可复制、可集成。对于团队而言，接入 Prettier 的意义不在于工具本身，而在于通过统一格式基线，降低协作摩擦，让代码回归可读性与可维护性的本质。