先说一个判断代码评审里最没有价值的讨论就是关于代码风格的讨论。这个括号要不要换行那个字符串该用单引号还是双引号缩进到底用两个空格还是四个空格——这类话题我在不同团队里经历了不下十次。最后真正终结争论的不是谁说服了谁而是 Prettier 配置的落地。所以这篇博文不打算从“Prettier 是什么”开始讲而是直接进入配置本身配置文件怎么组织、核心参数怎么影响输出结果、VSCode 里怎么和编辑器配合、跟 ESLint 怎么划清边界以及我在真实项目里踩过的几个坑。不管你是刚接触 Prettier 的新人还是想优化团队格式化流程的老手应该都能在这里找到可以直接抄走的内容。1. 从“括号要不要换行”说起Prettier 在解决什么问题1.1 格式化争论的真实成本我接手过一个三年历史的前端项目里面一半代码是 Allman 风格左大括号独立成行另一半是 KR 风格左大括号跟在行尾甚至同一个文件里两种风格交替出现。最离谱的一次一个只改了两个变量名的 PRdiff 里却多了两百多行跟功能无关的格式变化。reviewer 得手动跳过这些格式改动去找真正改动的那两行效率极低。这种问题不是什么“品味问题”它是有实际成本的每次 PR 的评审时间被拉长合并冲突的概率变高新人在老项目里改代码还要先猜“这个文件是什么风格”。我在很多团队里见过关于风格的讨论持续了几个月最后不了了之直到引入 Prettier这类讨论才彻底消失。Prettier 的核心定位是一个 Opinionated Code Formatter中文一般翻译成“有主见的代码格式化工具”。它的设计哲学是别和我讨论风格我来给你一套经过验证的默认方案你在关键开关上做选择就行。这种“独裁”恰恰是它最大的价值因为它把团队从无穷无尽的风格争论里解放出来。1.2 Prettier 和普通美化工具的本质区别很多人刚接触 Prettier 时会把它理解成另一个 beautifier或者我打开编辑器随便格式化一下的工具。实际上两者差别非常大。传统的美化工具大多是正则替换或基于简单字符串处理规则复杂不说遇到边界情况经常输出结果不稳定。Prettier 用的是编译器的思路先把代码解析成 AST抽象语法树再把 AST 按照自己的规则重新打印成代码。这意味着只要代码没有语法错误不管源代码被写成什么样Prettier 的输出结果永远是同一个标准化格式。这也解释了为什么 Prettier 不能做“把每一行的赋值语句末尾对齐”之类花哨的美化——AST 里根本没保存这些视觉排版信息它只关心语法结构。理解这一点后你就不会抱怨“Prettier 为什么不做成 xxx 风格”因为它的目标从来就不是让代码“更惊艳”而是让所有代码“长得一样”。1.3 Prettier 到底能管哪些语言Prettier 不是某个前端框架的附属工具它支持一大批语言和格式JavaScript、TypeScript、JSX、Vue、Angular、Flow、CSS、Less、SCSS、HTML、JSON、YAML、Markdown、GraphQL 等。团队里前端相关的大部分格式问题它都能覆盖。这也引申出一个常见问题既然有这么多语言是不是每个文件都会套同一套配置不是。Prettier 会自动识别文件类型不同语言会应用各自合适的规则。但像 printWidth、tabWidth、endOfLine 这类通用配置在绝大多数语言里都会生效。所以配置面板某种意义上是在“语言之间找最大公约数”。2. 配置文件与加载顺序Prettier 凭什么知道用哪份规则2.1 五种配置来源最容易搞混的就是优先级Prettier 的配置信息来源有五种package.json里的prettier字段专门的配置文件.prettierrc、.prettierrc.json、.prettierrc.yaml、.prettierrc.yml、.prettierrc.tomlJavaScript 配置文件prettier.config.js、.prettierrc.js也支持.cjs和.mjsCLI 参数比如npx prettier --write --print-width 100 file.jsVSCode 扩展在settings.json里的prettier.*配置项当你让 Prettier 格式化某个文件时它会从这个文件所在的目录开始一层一层向上查找配置文件。找到第一个配置文件后就把它当作这份文件的解析基准再加上 Prettier 内部的默认值补全最终形成完整配置。这里有一个很关键的细节Prettier 不会把根目录的配置和子目录的配置合并。假设项目根目录的.prettierrc.json设置了printWidth: 100src/components下又有自己的.prettierrc.json只设置了singleQuote: true那么格式化src/components/Button.jsx时printWidth会回到默认值 80而不是 100。因为 Prettier 找到最近的配置文件后就不再往上找了它也根本不会去合并这两份配置。所以我给团队做配置规范时基本都会强调一句话配置文件只在项目根目录放一份任何子目录不要放。如果你真的需要某个目录单独特殊处理那通常意味着代码本身有需要重构的信号而不是配置有缺陷。2.2 CLI 参数是最高优先级的“临时开关”在配置文件之外CLI 参数的优先级最高。比如你想临时验证一下不同行宽的效果npx prettier --write --print-width 120 src/index.js这个 120 会直接覆盖配置文件里的printWidth。这种用法适合临时测试但不建议写进脚本里因为脚本参数一旦和配置文件不一致团队成员看到的效果就会分裂。CLI 常见的几个命令值得记住npx prettier --check file只检查文件是否符合配置不修改内容CI 里经常用npx prettier --write file格式化并直接覆盖文件npx prettier --list-different src/**/*.{js,ts}列出所有和配置不一致的文件不改动内容npx prettier --write .格式化当前目录下所有能被识别且未被忽略的文件威力很大用之前务必检查.prettierignore2.3 VSCode 设置和项目配置到底谁说了算这个问题很多人没弄明白结果出现“本地格式化结果和同事不一致”的怪象。VSCode 扩展esbenp.prettier-vscode会把你写在settings.json里的prettier.printWidth、prettier.singleQuote这类配置作为扩展的默认值。当项目根目录没有配置文件时这些值才会生效。只要发现项目里有.prettierrc或prettier.config.jsPrettier 的配置解析逻辑就会以项目配置为准。换句话说同一个项目里如果每个人都按自己的口味修改 VSCode 设置而项目里恰好又没有配置文件那大家格式化出来的代码必然不一样。正确做法是把项目配置提交到仓库里然后告诉团队“不要自己在编辑器里写 prettier.* 设置统一用项目配置”。能不能做到这一点往往比选哪些配置项更重要。3. 逐项拆解常用配置从 printWidth 到 embeddedLanguageFormatting3.1 行宽与缩进printWidth、tabWidth、useTabsprintWidth默认值是 80它不是“最大字数”而是近似字符宽度。一行代码超过这个宽度时Prettier 会在它认为合适的位置折行而不是无脑硬换。这个值设得太小代码会频繁换行设得太大在高分辨率屏幕上阅读长行反而费劲。我实际项目里用得最多的是 100少数团队用 120。说实话80 在宽屏时代确实偏窄但 120 以上的折行判断又太宽松不同开发者的屏幕大小和分屏习惯还不一样100 是比较稳妥的折中。tabWidth默认 2决定一个缩进级别对应的空格宽度。注意它不决定“用空格还是 tab”那由useTabs控制。useTabs默认false也就是用空格缩进。有些团队喜欢 tab因为每个开发者可以在编辑器里自定义 tab 的显示宽度看到的效果各自不同。但用 tab 也会带来对齐不稳定的问题尤其是混用空格对齐的场景。我建议跟随默认值useTabs: false不要在这个配置上引入太多讨论节省精力。这里还有个容易误解的地方即使useTabs: truetabWidth依然有意义它会告诉 Prettier“一个 tab 等于多少个空格宽度”用于计算一行代码是否超过printWidth。3.2 引号、分号与对象属性引号semi、singleQuote、quotePropssemi默认true也就是行尾加分号。JavaScript 的自动分号插入机制ASI确实允许省略分号但省略分号的前提是每条语句得单独一行否则压缩、合并代码时容易出问题。团队里有人喜欢无分号风格有人喜欢有分号风格只要项目统一不管哪种都能接受。最怕的是没有配置两个人来回改diff 里全是分号的增删。singleQuote默认false输出双引号。很多人喜欢设成true理由是在 JSX/HTML 场景下字符串内容经常包含双引号属性用单引号可以减少转义。这个完全按团队偏好来但要注意它只影响 JavaScript/TypeScript 里的字符串不影响 JSX 属性里的引号后者由jsxSingleQuote单独控制默认也是false。quoteProps默认as-needed只有对象的属性名是关键字或包含特殊字符时才给属性名加引号。如果你希望统一加引号可以设consistent它的规则是如果对象里有一个属性名需要引号其他属性名也都加引号看起来更整齐。实际项目里保持默认as-needed最省心。3.3 尾逗号与括号布局trailingComma、bracketSpacing、bracketSameLine、arrowParenstrailingComma是我最推荐的“必开”配置。Prettier 3 里默认值是all老版本默认是es5差异在于函数参数和函数调用处是否加尾逗号。es5 模式只在数组、对象这些 ES5 支持的语法里加尾逗号函数相关的不加all则在函数参数、函数调用甚至import语句里也加。为什么要加尾逗号最直接的好处是减少 git diff 噪音。比如你有一个对象const config { name: test, version: 1.0.0, };下次要加一项author: zhangdiff 只在原来的version行尾巴和新增的author行显示而不会把version行整行标成删除修改。这在多人协作的代码评审里非常舒服。bracketSpacing默认true也就是对象字面量的大括号内部加空格输出{ foo: 1 }设false输出{foo: 1}。纯视觉偏好。bracketSameLine影响 JSX/HTML 标签的收尾默认false会被放到新行和属性缩进对齐。如果你不喜欢看到 JSX 里孤零零的独占一行可以设true会让紧跟最后一个属性之后。这个没有对错团队统一就行。arrowParens默认always箭头函数参数永远带括号输出(x) x设avoid会在只有一个参数时省略括号输出x x。我建议保持默认因为 TypeScript 项目中遇到泛型箭头函数时省略括号容易出现解析歧义而且参数数量一变括号从无到有也会造成无意义的 diff。3.4 行尾、嵌入代码格式化与单属性换行endOfLine、embeddedLanguageFormatting、singleAttributePerLineendOfLine默认lf。Windows 上如果项目文件原本是 CRLF运行 Prettier 后会被统一成 LF这一点许多人没意识到后面踩坑部分再展开。embeddedLanguageFormatting默认auto会让 Prettier 自动格式化嵌入在文件里的其他语言代码片段。比如 Markdown 代码块里的 HTML 或 CSS又比如 JS 模板字符串里的 Golang SQL 片段。如果你希望保留模板字符串里的原始内容特别是精心对齐过的 SQL把这个配置设为off就行。singleAttributePerLine默认false如果设成trueJSX/HTML 元素在需要折行时会变成每个属性占一行。属性非常多、评审时希望 diff 更清晰的组件场景这个配置很好用但它也会让一些属性本来两三个就能放下的行变得比较碎取舍看团队习惯。到这里给一份我常用的完整配置做参考{ printWidth: 100, tabWidth: 2, useTabs: false, semi: true, singleQuote: true, quoteProps: as-needed, trailingComma: all, bracketSpacing: true, bracketSameLine: false, arrowParens: always, endOfLine: lf, embeddedLanguageFormatting: auto, singleAttributePerLine: false }最后再说一句配置项不是越多越好能用默认的就不要动。每改一个配置团队里就多一类讨论。4. VSCode 里面把 Prettier 用顺手保存即格式化怎么配4.1 安装扩展并设为默认格式化器VSCode 用的扩展叫esbenp.prettier-vscode直接搜 Prettier安装量最大的那个就是。安装完成后有个关键细节容易被忽略很多文件默认格式化器不是 Prettier你要手动指定。最简单的方法是打开任意一个 JS 或 TS 文件右键选择“格式化文档”然后在弹出的下拉框里选 Prettier。如果想用配置固化下来在settings.json里加{ editor.defaultFormatter: esbenp.prettier-vscode }这个配置是全局的会影响所有语言。如果项目里同时有 Python、C而你又不想让 Prettier 去格式化它们建议按语言覆盖{ [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 只管 JS/TS/JSON/CSS 这些它擅长的Python 的格式化留给 BlackC 的格式化留给 clang-format彼此不干扰。4.2 保存即格式化与粘贴格式化保存时自动格式化是使用 Prettier 最爽的体验配置在settings.json{ editor.formatOnSave: true, editor.formatOnPaste: true }formatOnPaste有人喜欢有人不喜欢。喜欢是因为粘贴完代码马上变整齐不喜欢是因为如果粘贴的是不完整的片段Prettier 会立刻把不完整的代码按自己的规则排版结果可能看着更乱。我的建议是先开着实际用一段时间如果你觉得粘贴后反而更乱再把它关掉保留formatOnSave已经完全够用。这里还有一个隐藏的配置项editor.formatOnSaveMode默认值是file也就是保存时格式化整个文件。还有一个值modifications只格式化本次修改的行。听起来很美好但计算行级修改在编辑器里其实不太稳定遇到贴了一段代码、撤销、合并分支之类的操作容易出现漏格式化的情况。团队协作里我更推荐file因为它足够彻底配合接下来的.prettierignore就能控制好边界。4.3 用 .prettierignore 划定格式化边界项目里不是所有文件都应该被 Prettier 碰。我通常会在项目根目录放一份.prettierignorenode_modules dist build coverage .prettierrc.js package-lock.json yarn.lock pnpm-lock.yaml *.min.js *.min.css解释几个重点package-lock.json、yarn.lock、pnpm-lock.yaml是包管理器自动生成的格式化会破坏它的哈希结构绝对不要碰。dist、build、coverage是构建产物和测试覆盖产物每次构建都会重新生成格式化它们没有意义。*.min.js、*.min.css已经是压缩过的代码格式化会把它展开成几千行体积变大可读性反而更差。实际上 Prettier 默认会忽略node_modules但显式写出来有两个好处一是提醒阅读配置的人“这里刻意排除了什么”二是避免未来某些场景下行为变化。4.4 不同成员的编辑器配置不一致怎么办这个问题单独拿出来说。项目里有配置文件时VSCode 扩展会自动识别但如果没有配置文件每个人的settings.json可能都不一样。甲用双引号、乙用单引号两人改同一个文件每次提交都会互相覆盖。我曾在一个团队里见过最典型的场景项目根目录没有.prettierrc一个同事在 VSCode 里开了prettier.singleQuote: true另一个没设置默认双引号。两个人都以为“自己在用 Prettier”结果代码风格依然分裂。所以配置文件的第一个作用不是“调整风格”而是“建立共识”。没有项目级配置Prettier 并不能自动解决团队风格不一致的问题。5. Prettier 和 ESLint 的分工别让两个工具互相打架5.1 先划清边界格式归 Prettier质量归 ESLintESLint 里本身有大量排版规则比如semi、quotes、indent、max-len等等。在 Prettier 出现之前这些规则确实承担了一部分格式化职责。但 Prettier 出现之后继续在 ESLint 里开这些规则就会很痛苦一方面和 Prettier 的输出结果冲突另一方面会让eslint --fix和prettier --write互相改来改去。我推荐的分工方式很简单ESLint 只关心代码质量和潜在 bug比如未使用变量、不可达代码、函数复杂度、全局污染这类问题代码长什么样由 Prettier 负责ESLint 里的格式化规则全部关闭。5.2 方案一eslint-config-prettier 关闭冲突规则在.eslintrc里把 Prettier 的配置放在extends最后一项{ extends: [airbnb, prettier] }eslint-config-prettier做的事情是关闭所有和 Prettier 冲突的格式化规则。这里有个细节如果你用了plugin:vue/recommended或者plugin:typescript-eslint/recommended这类预设记得把prettier放在最后这样它才有机会覆盖掉前面预设里的格式规则。这个方案几乎没有任何额外性能开销因为它只是关闭规则不会真的去跑 Prettier。绝大多数项目我都推荐先用它。5.3 方案二eslint-plugin-prettier 把 Prettier 当 ESLint 规则跑另一种做法是把 Prettier 当作 ESLint 的一个插件规则配置如下{ plugins: [prettier], rules: { prettier/prettier: error } }这样eslint . --fix一条命令就能同时修质量问题和格式问题。它的缺点是ESLint 会为每个文件额外跑一遍 Prettier性能开销比较大在文件数量大的项目里尤其明显而且编辑器里 Prettier 扩展已经在做格式化ESLint 规则里再跑一遍属于重复劳动。有些团队也会把eslint-config-prettier和eslint-plugin-prettier一起用先关闭冲突规则再把 Prettier 作为规则加进来。这种组合能用但我个人觉得没必要既然 Prettier 已经负责所有格式输出ESLint 里再把它当规则跑一遍只为报错显示收益并不高。5.4 两种方案对比维度eslint-config-prettiereslint-plugin-prettier职责只关闭 ESLint 里的格式规则把格式问题变成 lint 报错性能几乎没有额外开销每个文件额外运行一次 Prettier编辑器体验Prettier 作为格式化器保存即生效格式错误会出现在 Problems 面板适用场景绝大多数项目希望一条命令统一处理 lint 和格式的团队5.5 VSCode 里同时使用两个扩展的设置如果安装了 ESLint 扩展注意别让它接管格式化。我的做法是在settings.json里{ eslint.format.enable: false, editor.codeActionsOnSave: { source.fixAll.eslint: explicit } }eslint.format.enable: false的意思是不让 ESLint 参与“格式化文档”的流程格式化只交给 Prettier。source.fixAll.eslint会在保存时让 ESLint 自动修复质量问题比如自动补分号、删未使用变量这些不涉及排版。两个工具在保存时会不会冲突我的经验是只要关掉 ESLint 里所有格式类规则并且不启用eslint.format.enable它们就能各管各的。ESLint 负责可修复的质量问题Prettier 负责排版的最终输出。6. 踩坑实录CRLF、格式化范围失控与大文件卡顿6.1 一次格式化让整个 git diff 全红这是我见过最经典的 Prettier 事故。一个 Windows 开发者提交的代码是 CRLF 行尾项目之前一直没统一处理。某天一个同事跑了一次npx prettier --write srcPrettier 默认endOfLine: lf于是所有文件的行尾从 CRLF 全变成了 LF。接下来git 里整个 diff 全红所有行都被标记成删除再新增代码评审直接没法做。排查链路是这样的先看git diff发现没有任何实际业务改动但每一行都被标记为 changed再检查文件行尾类型Windows 上是 CRLFPrettier 处理后变成 LF接着看 git 配置Windows 上一般默认core.autocrlftruecheckout 时把 LF 转成 CRLF提交时又转回 LF这种“我的本地是 CRLF、仓库里是 LF”的双轨制让问题更隐蔽。解决方案要三管齐下项目根目录加.gitattributes写上* textauto eollf让 git 统一按 LF 存储。团队成员设置git config core.autocrlf建议 Windows 开发者也统一用 LF 作为最终行尾。Prettier 配置里显式写endOfLine: lf避免默认值变化带来的意外。行尾问题在跨平台团队里迟早会遇到早点在.gitattributes和 Prettier 配置里统一后面能省非常多事。6.2 格式化范围失控一不小心动了整个老项目老项目里格式化问题更尴尬。你只是在文件里改了一行代码保存时 Prettier 把整个文件按新配置重新排版diff 里冒出几百行无关改动。功能上没问题但代码评审的人会炸毛。处理这个问题有两个方向。第一个方向先做一次全量格式化提交跑npx prettier --write src然后把这次改动作为独立的style: formatcommit 提交。之后的每一次功能改动因为文件已经被格式化过了保存时不会再产生额外的大面积改动。这个顺序很重要先让格式化成为历史再做功能开发。第二个方向如果团队暂时不想接受全量格式化可以用 lint-staged 把 Prettier 约束在“本次真正改动的文件”上配合 husky 在提交前自动格式化。这样历史上那些旧文件依然保持原样但新改动提交进仓库前已经统一格式。老项目改造的正确节奏就是先分模块全量格式化再加 lint-staged 和 CI 检查一步一步来不要想着一天之内把几千个文件全刷一遍。6.3 模板字符串里的 SQL 被“善意”地打乱Prettier 的embeddedLanguageFormatting默认auto它会把嵌入在模板字符串里的 HTML、CSS、SQL 等也尝试重新格式化。初衷是好的但实际项目中经常出现问题有人在前端代码里写了精心对齐的 SQL 查询模板开启 Prettier 后 SQL 被重排缩进和换行全变了甚至某些方言语法被格式化后可读性变差。这不是 bug而是这个配置项的设计预期。解决方式很直接如果你希望模板字符串内容保持原样把embeddedLanguageFormatting设为off即可。不过要注意这个配置是全局的关了以后所有嵌入代码片段都不再自动格式化。如果你的项目主要用 JavaScript建议直接设为off因为你根本不知道哪段模板字符串里藏着需要保留原始格式的 SQL 或 GraphQL。6.4 超大文件与格式化卡顿Prettier 的性能已经算好的但遇到几千行的超大文件比如很大的 JSON 配置、很长的 Markdown 文档按一次保存可能要卡一两秒。团队里如果有人电脑配置差一点体验就是“每次保存都像卡死”。我的处理思路是分情况看。如果这个文件确实需要格式化那就忍一下或者把 VSCode 的formatOnSave只针对 JS/TS 等语言开启减少无关文件的触发机会。如果这个文件根本不需要格式化比如它是一个由脚本生成的 JSON直接把它加进.prettierignore。如果只是偶尔需要格式化某个超大文件的局部内容用选中区域后右键“格式化选定内容”会更合适。6.5 团队没有项目级配置导致的“互相覆盖”这个我已经在前面反复提到过但它是实际项目里排第一的问题值得再给一个完整的排查思路。现象是两个人用同一个 VSCode 扩展代码风格却不一样更隐蔽的是一个人改了配置之后另一个人没改格式化的结果就开始互相打架。排查路径很简单打开一个文件运行“格式化文档”看 Prettier 输出用的到底是什么配置。如果项目根目录有.prettierrc或prettier.config.js就以它为准如果找不到配置文件所有prettier.*设置都会退回到用户级的settings.json每个人不一样太正常了。解决方式不是去讨论“谁的对”而是在仓库根目录提交一份配置文件并且在 CI 里加一步检查npx prettier --check .任何人和配置不一致的代码都过不了 CI这才是团队层面的终极兜底。7. 团队落地共享配置、提交钩子与老项目改造7.1 把配置沉淀成共享包如果你的团队有多个前端项目风格完全靠复制粘贴.prettierrc太容易漂移。一个更规范的做法是做私有 npm 包比如scope/prettier-config然后在项目里引用它。用 JavaScript 配置文件最直白// prettier.config.js module.exports { ...require(scope/prettier-config), // 项目特有覆盖写在这里 semi: false, };Prettier 3 的配置文件里还支持extends字段可以直接在 JSON 配置里扩展{ extends: scope/prettier-config, printWidth: 120 }共享包的好处是想调整团队风格只需要改一个包的版本然后让各个项目升级依赖即可不用挨个项目改配置。7.2 husky lint-staged提交前自动格式化lint-staged 解决了“只格式化本次提交的暂存文件”的问题。配合新版 husky通常的配置是package.json里加{ lint-staged: { *.{js,ts,jsx,tsx,vue,json,md,css,scss,html}: [prettier --write] } }然后在.husky/pre-commit脚本里写npx lint-staged这样每次git commit前只有暂存区的这些文件会被 Prettier 格式化格式化完自动重新暂存。未暂存的文件完全不受影响。这个方案的巧妙之处在于它把格式化的动作前置到了提交之前而不是依赖每个人记得保存时格式化。CI 里的prettier --check是最后的防线lint-staged 是让日常开发无痛的常规操作。7.3 老项目改造的正确节奏最后聊老项目怎么引入 Prettier。最好不要一上来就npx prettier --write .然后微笑着看 CI 全部变绿。老项目的核心风险是全量格式化之后所有文件在 git 历史里都被刷了一遍做 git blame 的时候你再也分不清某一行代码是什么时候被改的。推荐流程分三步按模块分批格式化每批一个独立 commitcommit message 写上style: format xxx module with prettier。这样万一哪批格式化有副作用可以单独回滚。每个模块格式化完立刻在 CI 里加入prettier --check确保该模块后续改动必须符合格式要求。用 lint-staged 保证日常提交前已经格式化避免“新改动把旧格式又带进来”。这个节奏慢一点但安全、可控代码评审的人不会因为几千行无关注 diff 而崩溃。如果你问我这几年在团队推广 Prettier 最实用的经验是什么我会说配置本身不需要很复杂那十几个常用项已经覆盖了绝大多数场景真正需要花心思的是让配置文件出现在仓库里并且让 CI 说话。格式化这件事越早定下来后面越省心。另外一个小技巧每次升级 Prettier 大版本之后记得先跑一次npx prettier --check src看看新版的默认值有没有把你现有项目判定为不通过。有的话优先处理这种由工具升级驱动的格式变更再继续新的功能开发就不会把格式问题和业务改动搅在一起了。