4.1编辑器保存时格式化

4.1 编辑器保存时格式化

为什么这是最重要的集成

在所有 Prettier 集成方式中，编辑器的"保存时格式化"（Format on Save）对开发者体验的影响最大。

想想你的工作流：你写完一段代码，按 Ctrl+S 保存，然后继续写下一段。如果保存的瞬间代码被自动格式化了——缩进纠正了、空格补上了、换行调整了——你的工作流完全没有被打断。你不需要额外运行任何命令，不需要记住任何快捷键，格式化就是保存操作的一部分。

这跟"写完所有代码后手动运行 prettier --write"的体验截然不同。后者要求你有意识地"格式化"这个动作，意味着你要记得做、要切换到终端、要等命令执行完。每多一步，就有一次忘记的可能。

VS Code 配置

VS Code 是前端开发中占有率最高的编辑器。配置保存时格式化的步骤：

第一步：安装 Prettier 扩展。在 VS Code 扩展商店搜索 "Prettier"（发布者是 Prettier 官方，ID: esbenp.prettier-vscode），点击安装。

第二步：配置 VS Code 把 Prettier 作为默认格式化器。在项目的 .vscode/settings.json 中添加：

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}
​

这会让 VS Code 在保存任何文件时自动调用 Prettier 格式化。如果你想只对特定文件类型启用：

{
  "editor.formatOnSave": true,
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[css]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}
​

第三步：确保 Prettier 配置文件存在。Prettier 扩展会自动查找项目根目录的 .prettierrc 文件，读取配置。不需要额外的配置来连接 VS Code 和 .prettierrc——扩展自己会找到它。

WebStorm / IntelliJ 配置

JetBrains 系列编辑器内置了对 Prettier 的支持，不需要安装额外插件。

配置路径：Settings/Preferences → Languages & Frameworks → JavaScript → Prettier

勾选 "On 'Reformat Code' action" 和 "On save"，然后指定 Prettier 包的路径。WebStorm 会自动查找 node_modules/.bin/prettier，通常不需要手动填。

图 4-1：VS Code 与 WebStorm 的 Prettier 集成对比

Vim / Neovim 配置

Vim/Neovim 用户通过 coc.nvim 或 null-ls 来集成 Prettier：

-- 使用 null-ls（Neovim）
local null_ls = require("null-ls")
null_ls.setup({
  sources = {
    null_ls.builtins.formatting.prettier,
  },
})

-- 保存时自动格式化
vim.cmd([[autocmd BufWritePre *.js,*.ts,*.jsx,*.tsx,*.css,*.json lua vim.lsp.buf.format()]])
​

Sublime Text 配置

通过 Sublime Text 的包管理器安装 JsPrettier 插件，然后在配置中设置保存时触发。

只格式化选中的代码

VS Code 的 Prettier 扩展支持"格式化选中区域"：选中一段代码，执行 Format Selection（默认快捷键 Ctrl+K Ctrl+F），只有选中部分被格式化。这个功能在以下场景很有用：

• 某个历史遗留文件整体格式化会产生巨大 diff，但你只想整理刚写的几行
• 某个第三方生成的代码片段不需要全文统一风格
• 你正在阅读别人写的旧代码，想临时排版看清结构，又不想留下改动

注意：格式化选中区域时，Prettier 仍然按完整语法树处理，所以如果选区切在语句中间，可能无法格式化或结果不符合预期。选区最好从语句边界开始。

让某些文件跳过格式化

即使全局启用了 formatOnSave，也有一些文件不希望被自动格式化。常见的有：package-lock.json（内容由 npm 生成且格式固定）、构建产物目录、自动生成的类型声明。

处理方式有三种。

第一种，在 .prettierignore 中排除，Prettier 扩展会尊重这个文件：

package-lock.json
dist/
generated/
​

第二种，对单个文件类型关闭保存格式化：

{
  "[json]": {
    "editor.formatOnSave": false
  }
}
​

第三种，在文件开头或语句前写 // prettier-ignore（JavaScript/TypeScript）或 <!-- prettier-ignore -->（HTML）注释，跳过特定语句或整个文件。这部分细节在 3.3 节有完整说明。

常见问题排查

保存后没有格式化。按顺序检查：扩展是否安装（状态栏出现 Prettier 图标）→ editor.formatOnSave 是否为 true → 该语言是否被语言级设置覆盖 → 文件是否在 .prettierignore 里 → 是否设置了 editor.formatOnSaveTimeout（默认 750ms，超时会中止格式化）。

格式化结果和命令行不一致。扩展默认使用项目本地安装的 Prettier（node_modules 里的版本），找不到时回退到扩展内置版本。如果项目用了 monorepo 或 pnpm workspace，扩展可能找到错误位置的配置。可以在扩展设置里显式指定 prettier.prettierPath，指向项目根目录的本地安装。

格式化报语法错误。通常是文件本身有语法问题（比如未闭合的括号）。Prettier 无法格式化语法错误的文件，先修语法再保存。

注意事项

项目级安装 vs 全局安装。建议项目级安装（npm install --save-dev prettier），这样团队成员使用相同版本的 Prettier。如果用全局安装，不同机器上的 Prettier 版本可能不一致，导致格式化结果出现细微差异。

ESLint 扩展的冲突。如果 VS Code 同时安装了 ESLint 扩展和 Prettier 扩展，且都启用了保存时自动修复，可能会出现"ESLint 先修、Prettier 后修"的冲突。解决方案是确保 ESLint 配置中通过 eslint-config-prettier 关闭了格式规则（见 1.3 节），然后禁用 ESLint 扩展的 "eslint.autoFixOnSave"，只保留 Prettier 的 "editor.formatOnSave"。

性能考虑。Prettier 扩展在格式化时会启动一个 Node.js 子进程。对于大文件（几千行以上），格式化可能需要几百毫秒。如果你的项目文件普遍很大，可以考虑把 formatOnSave 限制在特定文件类型上，避免在打开大 JSON 文件时也触发格式化。

团队共享编辑器配置。VS Code 的项目级设置文件 .vscode/settings.json 应该提交到版本控制中。这样团队中的每个开发者打开项目时，自动获得相同的格式化配置。这是一个容易被忽略但很重要的细节——如果编辑器配置不一致，即使项目有 .prettierrc，某些开发者可能因为编辑器没有启用保存格式化而提交未格式化的代码。

编辑器集成是 Prettier "无感自动化"的第一层。它处理了日常编码中的格式化需求，让格式化成为保存动作的自然延伸。但编辑器集成有一个局限——它依赖每个开发者自己配置。如果某个开发者忘了安装扩展或没有启用保存格式化，未格式化的代码仍然可能流入代码库。下一节介绍的 Git Hooks 能堵住这个漏洞。