1. Nuxt 项目里代码风格失控的隐性成本接手一个跑了半年多的 Nuxt 项目最典型的场景是这样打开pages/index.vue发现第一个人的缩进是 2 空格第二个人的是 4 空格第三个文件末尾缺了个换行符第四个组件的script setup缩进方式又完全不同。git diff里一半的改动是在调整空格和引号真正的业务逻辑被淹没在几百行无效变更里。这种项目通常不会因为格式乱就崩掉但它会持续消耗团队的时间——代码评审时不好意思提这种事提了显得吹毛求疵不提又越积越多最后所有人在心里默默给这个仓库贴上历史包袱重的标签。Prettier 就是在这种场景下被引入的。它是一款固执己见的代码格式化工具只干一件事把代码解析成 AST再按固定规则重新打印出来。它不关心你的变量名叫data还是userList也不管你的函数写了几行只负责缩进、引号、分号、换行这些排版层面的问题。在 NuxtJS 项目里.prettierrc这个配置文件承担的角色就是把这套排版规则固化成团队共识让所有人的编辑器、命令行、CI 环境输出同一份代码形态。这篇内容写给三类人刚上手 Nuxt 3、被npm run lint报错劝退的新人带团队、想给仓库补上格式化流程的技术负责人以及那些配了.prettierrc却发现保存后没变化、正在怀疑人生的开发者。全文围绕.prettierrc的配置逻辑、落地步骤、与 ESLint 的协作边界、存量项目的迁移姿势展开涉及参数会解释为什么这么选涉及操作会给出可以直接复制的配置片段。1.1 为什么 Nuxt 比普通前端项目更容易乱Nuxt 的项目结构天生比单纯的 Vue 项目复杂。一个典型的 Nuxt 3 仓库里同时躺着.vue、.ts、.mjs、.json、.css、.md六种以上文件类型还有server/目录下的 Nitro 服务端代码、app.vue入口、pages/路由约定、composables/自动导入目录。每种文件类型的默认排版习惯都不一样JSON 不允许尾逗号CSS 的嵌套缩进又是一套规则Markdown 里还混着代码块。更要命的是 Nuxt 的自动导入机制。composables/、utils/下面的文件会被框架自动扫描.nuxt/目录在nuxt dev启动时动态生成类型声明文件。如果格式化工具没有把这些目录排除掉你会遇到两种情况一是格式化进程扫描到几万个自动生成的.d.ts文件跑到天荒地老二是每次启动开发服务器.nuxt/里的文件都被改写一遍git status一片红。我把这类问题归成一句话Nuxt 项目的格式化难点不在规则本身在于哪些文件该管、哪些文件绝对不能碰的边界划分。.prettierrc负责前者.prettierignore负责后者两个文件必须一起配缺一个都会出问题。1.2 Prettier 和 ESLint 各管一段别让它们打架新手最容易犯的错是把 Prettier 和 ESLint 当成同一类工具装了一个就以为万事大吉。这两者的职责边界其实非常清晰维度PrettierESLint关注点代码长什么样排版代码是什么意思逻辑典型规则缩进宽度、引号类型、换行位置未使用变量、v-for缺:key、await误用能否自动修复全量重排部分规则可修部分只能报错是否理解语义基本不理解理解输出形态直接改写文件只读检查带--fix才改写真正的冲突点在 ESLint 那批风格类规则上比如indent、quotes、semi、max-len、comma-dangle。这些规则做的事情和 Prettier 完全重叠而且实现细节不一致——Prettier 认为 82 个字符放得下就该放一行ESLint 的max-len可能在 80 就报错。两个工具来回改文件就变成了拉锯战现场。我的做法很简单风格类规则全部交给 PrettierESLint 只保留语义检查。具体实现就是引入eslint-config-prettier它会把所有与 Prettier 冲突的 ESLint 规则一次性关掉。这件事在 Nuxt 项目里尤其重要因为nuxt/eslint生成的配置里默认带了不少风格规则。注意不要同时装eslint-plugin-prettier和eslint-config-prettier却搞不清分工。前者是把 Prettier 当成一条 ESLint 规则来跑性能差、报错信息难读后者是关掉冲突规则。两者用途完全不同混用是常见踩坑点。到这里思路就清楚了.prettierrc定规则.prettierignore划边界eslint-config-prettier消冲突编辑器保存动作和命令行脚本负责执行。四件事凑齐这套流程才算真正可用。2..prettierrc的配置项逐条拆解配置文件本身不难难的是每个选项背后的取舍。我见过不少项目直接从网上抄一份配置贴进去跑起来也没报错但团队里没人说得清printWidth为什么是 100 而不是 80trailingComma为什么用all。等到某天需要统一调整讨论就变成了主观审美辩论。2.1 选对文件格式别给自己挖坑Prettier 支持的配置文件格式相当多优先级从高到低大致是package.json里的prettier字段、.prettierrc无扩展名按 JSON 或 YAML 解析、.prettierrc.json、.prettierrc.yml、.prettierrc.json5、.prettierrc.js/.cjs/.mjs、prettier.config.js/.cjs/.mjs/.ts、.prettierrc.toml。Nuxt 官方模板习惯用无扩展名的.prettierrc内容就是纯 JSON。这个选择的好处是直白任何编辑器都能高亮缺点是不能写注释也不能做逻辑判断。如果团队规模不大、配置不会动态变化用它是够了。需要写注释或者根据环境切换配置时我推荐.prettierrc.mjs// .prettierrc.mjs /** type {import(prettier).Config} */ export default { semi: false, singleQuote: true, printWidth: 100, trailingComma: all, tabWidth: 2, useTabs: false, bracketSpacing: true, arrowParens: always, endOfLine: lf, vueIndentScriptAndStyle: false, htmlWhitespaceSensitivity: css, }/** type {import(prettier).Config} */这一行 JSDoc 注释很值钱它让编辑器在写配置时给出类型提示和补全拼错选项名时立刻标红。很多人不知道 Prettier 对未知选项是静默忽略的——你把printWidth敲成printwidth它不会报错只会安静地用默认值 80然后你纳闷为什么设了 100 没生效。这里有个重要细节必须提Prettier 3.0 开始不再支持.prettierrc.ts无对应 loader要用 TypeScript 写配置得走prettier.config.ts这个文件名。版本差异导致的配置读不到是升级后突然格式化失效的高频原因。2.2 真正影响 diff 体积的那几个选项配置项有二十多个但真正决定团队协作体感的就那么五个。我把它们单独拎出来讲是因为这些选项一旦定下来短期内不该再改——中途改会让全仓库产生一次巨型 diff。printWidth换行阈值不是硬性字符上限。默认 80很多 Nuxt 项目会调到 100 或 120。原因是 Vue 模板里嵌套三层 div 加上属性绑定80 列根本撑不住会逼出大量的多行展开代码纵向长度爆炸。我个人的取值是 100配合singleAttributePerLine: false让多个短属性尽量待在一行。判断标准很简单拿项目里最长的一个template块试两种取值看哪种读起来更顺。这里要澄清一个普遍误解——printWidth不是超过就强制断行Prettier 会在超过阈值的地方寻找合适的断点某些长字符串或长注释它也无能为力。trailingComma尾逗号策略。取值有none、es5、all。Prettier 3 把默认值从es5改成了all也就是函数参数、函数调用也加尾逗号。all的好处是增删参数时 diff 永远只动一行坏处是老项目迁移时会产生一次性的大量变更。新项目我建议直接all。semi和singleQuote纯风格偏好但必须有结论。semi: false意味着不写行尾分号singleQuote: true意味着字符串用单引号。这两个选项没有对错但团队里必须只有一种答案。我见过一个仓库里两种风格并存原因是 CI 的prettier --check在某个分支上被跳过了几百个文件带着混合风格合进了主干后面再想统一就得处理一堆格式化冲突。endOfLine换行符跨平台协作的隐形杀手。默认是lf。如果团队里有使用 Windows 的成员且 Git 没配core.autocrlf那么每次提交都可能出现整个文件都被修改的假象——实际只有换行符从CRLF变成了LF。配置里显式写endOfLine: lf同时在仓库根目录加一个.gitattributes# .gitattributes * textauto eollf *.png binary *.jpg binary这两处配合跨平台的行尾问题基本就绝迹了。这一条在多人协作项目里的收益远超其他所有配置项但偏偏最容易被忽略。选项默认值Nuxt 项目推荐值选它的理由printWidth80100模板嵌套深80 列会大量纵向展开tabWidth22与 Vue 生态、ESLint 默认保持一致semitrue按团队约定必须唯一不能混用singleQuotefalsetrue与主流 JS 社区习惯一致减少转义trailingCommaallall增删末尾项时 diff 只动一行endOfLinelflf消除跨平台 CRLF 造成的假变更arrowParensalwaysalways单参数箭头函数也保留括号后续加参数不用改2.3 Vue 单文件组件专属的两个选项vueIndentScriptAndStyle和htmlWhitespaceSensitivity这两个选项只对.vue文件生效但影响面很大。vueIndentScriptAndStyle默认false意思是script和style标签内部的代码不相对标签缩进script setup langts const count ref(0) /script style scoped .title { color: red; } /style改成true之后内部代码会整体右移两个空格。没有绝对优劣但我建议保持默认false——一来这是 Prettier 官方默认和社区教程一致二来在较长的script setup里多两级缩进在窄屏编辑器上会挤压实际可用宽度。htmlWhitespaceSensitivity控制 HTML 空白的敏感度取值css默认、strict、ignore。Nuxt 项目一般不用动。唯一需要留意的是如果你的模板里存在依赖空白字符实现间距的写法比如两个span之间靠空格控制字间距ignore模式可能把空白吃掉导致视觉变化。真遇到这种情况正确的解法是用 CSSmargin或gap控制间距而不是指望格式化工具保留空白——依赖格式化工具保留空白的代码本身就是脆弱的。2.4 插件扩展与配置复用Nuxt Tailwind 的项目大概率会用到prettier-plugin-tailwindcss。它做的事情是按 Tailwind 的推荐顺序自动重排 class 字符串把text-white p-4 flex排成flex p-4 text-white。好处是团队里所有人的 class 顺序一致评审时能快速发现这个元素少了个 padding坏处是它依赖 Tailwind 配置解析如果tailwind.config.ts写得有问题插件会静默失败。安装和启用pnpm add -D prettier prettier-plugin-tailwindcss// .prettierrc.mjs export default { plugins: [prettier-plugin-tailwindcss], tailwindConfig: ./tailwind.config.ts, }注意Tailwind v4 之后配置方式有变化CSS-first 配置下tailwindConfig字段可能不适用插件改用tailwindStylesheet指向 CSS 入口。升级时这一步要单独验证别直接沿用旧配置。关于配置复用Prettier 原生不支持extends。想在多个仓库间共享一份配置有两条路一是把配置对象抽成一个小的 npm 包比如your-scope/prettier-config然后在.prettierrc.mjs里import展开二是在 monorepo 里通过 workspace 引用共同文件。第一种更规范第二种更省事。这里顺带说一句your-scope/prettier-config这类包名里的 scope 用的是虚构占位实际项目里换成自己的组织名即可。3. 让规则真正跑起来ESLint、编辑器与 CI 三方打通配置写完了不等于生效。我见过太多仓库里躺着一份漂亮的.prettierrc但实际提交上来的代码风格依旧五花八门。原因通常只有三个编辑器没配默认格式化器、ESLint 的冲突规则没关、CI 没有卡口。这一节把三件事一次说清。3.1 消解 ESLint 与 Prettier 的规则冲突Nuxt 3.9 之后官方推荐用nuxt/eslint模块它生成的是 ESLint 扁平配置eslint.config.mjs。传统.eslintrc那套写法正在退场配置方式变化很大网上很多老教程直接照抄会踩坑。安装pnpm add -D eslint nuxt/eslint eslint-config-prettier// eslint.config.mjs import withNuxt from ./.nuxt/eslint.config.mjs import eslintConfigPrettier from eslint-config-prettier export default withNuxt( { rules: { vue/multi-word-component-names: off, }, }, eslintConfigPrettier, )关键在于eslintConfigPrettier必须放在最后。它的作用是把所有与 Prettier 冲突的规则置为off如果放在前面后面加载的 Nuxt 配置会把它们又打开。这个顺序问题坑过不少人表现是明明装了却没效果。另外一个容易忽略的点eslint-plugin-prettier我没放进方案里。它把 Prettier 包装成 ESLint 规则好处是报错统一坏处是格式化要经过 ESLint 的 AST 流程大仓库上慢得明显而且报错信息被 ESLint 的格式套娃了一层很难读懂。分开跑两个命令各司其职体验反而更好。3.2 编辑器保存即格式化这一步决定了日常开发的实际体验。以 VSCode 为例在工作区里建.vscode/settings.json{ editor.defaultFormatter: esbenp.prettier-vscode, editor.formatOnSave: true, editor.codeActionsOnSave: { source.fixAll.eslint: explicit }, [vue]: { editor.defaultFormatter: esbenp.prettier-vscode }, [typescript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [json]: { editor.defaultFormatter: esbenp.prettier-vscode }, prettier.requireConfig: true }这里有两个值得说的细节。prettier.requireConfig: true让扩展只在存在配置文件时才格式化避免打开一个临时脚本也被改写格式。source.fixAll.eslint: explicit是 VSCode 新版本要求的写法老版本用true版本不匹配时这个设置会静默失效。再建一个.vscode/extensions.json推荐插件{ recommendations: [ esbenp.prettier-vscode, dbaeumer.vscode-eslint, Vue.volar ] }这里必须提一个高频冲突Vue 官方扩展 Volar 自带了格式化能力。如果 Volar 的vue.format.enable没关它可能抢在 Prettier 前面处理.vue文件导致模板部分的格式和.prettierrc不一致。稳妥的做法是在设置里显式指定[vue]的默认格式化器为 Prettier如上所示。提示如果保存后文件没有任何变化先检查右下角状态栏的格式化器名称。显示的是 Vue Language Features 就说明没切过来点击切换成 Prettier 即可。3.3 命令行的脚本设计编辑器解决了个人体验命令行解决的是团队一致性。package.json里加两条脚本{ scripts: { format: prettier --write ., format:check: prettier --check . } }--write直接改写文件日常开发用--check只检查不修改CI 用。这里有个小坑prettier --write .会递归当前目录如果.prettierignore写得不到位它会一头扎进.nuxt/、.output/这些生成目录。在 CI 里加一步# 片段示意 - name: Check formatting run: pnpm format:check有人会问既然编辑器保存时已经格式化过了CI 还需要查吗我的答案是必须查。原因很现实不是所有开发者都配了保存即格式化也有人用别的编辑器还有人会在网页端改一个错别字就提交。CI 是最后一道闸门把我觉得格式没问题变成工具确认格式没问题。3.4 提交前钩子把问题拦在本地CI 报错的反馈周期太长等流水线跑完再改成本高。提交前钩子能把格式化压在本地完成。Nuxt 官方模板里用的是simple-git-hookslint-staged这套组合比 husky 轻量。pnpm add -D simple-git-hooks lint-staged{ simple-git-hooks: { pre-commit: pnpm lint-staged }, lint-staged: { *.{js,ts,mjs,cjs,vue,json,css,md}: [ prettier --write ] } }装完之后执行一次pnpm simple-git-hooks钩子才会真正写入.git/hooks。这一步漏掉的症状很典型配置文件写得没问题但git commit时毫无反应。很多人以为是配置没生效其实是钩子根本没装上。lint-staged只处理暂存区文件这点设计很关键——它意味着格式化一次提交只影响本次改动不会顺手把仓库里其他没碰过的文件全改了避免混入无关变更。还有一个组合玩法值得推荐prettier --write之后紧接eslint --fix让 ESLint 处理那些语义层面的自动修复比如自动移除未使用的 import{ lint-staged: { *.{js,ts,mjs,cjs,vue}: [ prettier --write, eslint --fix ], *.{json,css,md}: [ prettier --write ] } }顺序不能反。先 Prettier 排版再 ESLint 修语义反过来的话 Prettier 会把 ESLint 刚修好的代码重新排一遍虽然多数情况下结果一样但偶尔会触发二次改动让暂存区状态变得不可预期。4..prettierignore与 Nuxt 特殊目录的边界处理.prettierignore这个文件常年被低估。它和.gitignore语法一致基于 gitignore 规则但用途完全不同前者告诉格式化工具别看这些后者告诉 Git别提交这些。两者有交集但绝不能混用同一份。4.1 必须忽略的目录清单Nuxt 3 项目里以下几类必须进.prettierignore# .prettierignore node_modules .nuxt .output .nitro .cache dist coverage pnpm-lock.yaml package-lock.json yarn.lock public逐个说理由。.nuxt是nuxt dev和nuxt build生成的类型声明与构建产物目录内容随代码变化自动重写格式化它毫无意义纯属浪费 CPU。.output是nuxt build的产物.nitro是 Nitro 服务端构建的临时目录同理。.cache里放的是各种工具的缓存。pnpm-lock.yaml这类锁文件必须排除原因是它们由包管理器生成手改会破坏完整性校验而且体积极大格式化一次可能要几秒到几十秒。public目录的处理要谨慎。它下面通常是图片、字体、favicon 等静态资源格式化工具不会去动二进制文件但如果有手写的.html或.js比如某些第三方验证文件格式化有可能改变其行为。我的做法是整体排除真有需要单独格式化的文件用!前缀反向包含public !public/sitemap.config.js这里要注意留一个心理预期如果.prettierignore里的规则写错最典型的症状是format:check在 CI 上卡住好几分钟或者报出几百个.nuxt/下的文件格式不符。看到这类报错第一反应应该是翻.prettierignore而不是去改代码。4.2 忽略规则的优先级与调试方法.prettierignore的规则遵循 gitignore 语义后面的规则可以覆盖前面的!表示反向包含/开头的模式相对于配置文件所在目录。调试忽略规则有个很实用的办法直接用--check看哪些文件被纳入了处理范围npx prettier --check . --loglevel debug调试日志会打印出每个被跳过的路径和原因比盲猜快得多。另一种办法是直接指定单个文件测试npx prettier --check pages/index.vue如果单文件能过、全量跑不过问题基本锁定在忽略规则或者某个特殊文件上。还有一个隐藏坑Prettier 从 3.x 起支持--ignore-path参数指定多个忽略文件但默认只读仓库根目录的.prettierignore。在 monorepo 里子包有自己的.prettierignore是不会自动被读取的得靠脚本参数显式指定。这个细节在单仓库项目里遇不到一旦拆了包就会突然暴露出来。5. 存量项目落地一次全量格式化的正确姿势新项目配好就完事存量项目才是真正的硬骨头。一个跑了两年、几百个.vue文件的仓库直接跑prettier --write .会瞬间改动几千个文件git log被一次巨型提交污染git blame全部指向格式化提交追查历史问题时痛不欲生。5.1 分步落地别一把梭我的操作顺序是这样的每一步都能独立验证、独立回滚第一步先只加配置文件和忽略文件不跑格式化。提交一个 commit让仓库具备能被格式化的能力但代码还没变。这一步风险为零。第二步跑prettier --check .看看规模npx prettier --check . 21 | tail -20输出末尾会统计有多少文件不符合格式。如果只有几十个可以直接跑如果是几千个说明得走分批策略。第三步分批格式化。按目录切分比如先components/再pages/再composables/每次单独提交npx prettier --write components/**/*.vue git add components git commit -m style: format components with prettier分批的好处是万一某个目录里藏着依赖特定格式的代码比如某些模板字符串里嵌了 YAML或者快照测试的期望值是精确字符串问题能立刻定位到具体批次。第四步处理测试快照。如果项目里有快照测试Jest、Vitest 的toMatchSnapshot格式化很可能让快照全部失配。这一条必须提前想到否则 CI 会一片红。处理方式是在格式化前先跑一次--updateSnapshot之前的状态确认格式化后再更新快照并单独提交。第五步全部格式化完成后再开 CI 卡口。顺序很重要——如果先开 CI 检查再格式化中间所有 PR 都会因为格式问题失败团队体验极差。5.2 用.git-blame-ignore-revs保住 blame 的可读性这是我认为最值得推广的一个技巧。Git 支持一个配置让git blame跳过指定的提交# .git-blame-ignore-revs # 全量格式化提交不参与 blame a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0文件里一行一个 commit hash写注释说明每个提交的用途。然后每个开发者本地执行一次git config blame.ignoreRevsFile .git-blame-ignore-revs或者直接改全局配置git config --global blame.ignoreRevsFile .git-blame-ignore-revs配好之后git blame会自动跳过格式化提交直接指向真正的业务改动。VSCode 的 GitLens 插件也识别这个文件行内 blame 提示会一并干净掉。注意这个机制只影响blame不影响log、diff、revert。提交历史本身仍然带着那次巨型变更这是无法避免的代价。所以前面强调的分批提交策略依然有价值——批次越细将来用git log --follow追单个文件历史时越容易。5.3 灰度推进的节奏控制再补一条实操经验。团队引入格式化最容易翻车的不是技术是节奏。我的建议是先在小范围试点找一个两三个人协作的模块把配置和流程跑通收集一周反馈。确认没问题后再推全仓库。推进时选一个业务低峰期比如周四下午留出一天缓冲别在发版前一天搞。另外提前和团队说清楚一件事格式化提交不要和业务改动混在同一个 commit 里。这个约定比任何工具配置都管用。混在一起的后果是 code review 时肉眼看不出业务逻辑改了啥评审质量直线下降。真要图省事可以在lint-staged之外要求每次业务提交前先本地跑一次pnpm format让格式化变更单独成提交。6. 常见问题与排查实录配了这么久踩过的坑够写一本小册子。挑几个最高频的整理成速查表附上排查路径。6.1 保存后没反应按这个顺序查这是我被问得最多的问题。排查逻辑是有顺序的别乱试。第一查编辑器右下角的格式化器是谁。VSCode 打开一个.vue文件右下角会显示当前默认格式化器。如果显示的是 Vue Language Features 或者 None切到 Prettier。第二查配置文件能不能被找到。Prettier 扩展有个命令面板入口 Prettier: Show Output Channel里面会打印它加载了哪个配置、解析出的最终选项是什么。这个面板是排查配置问题的第一现场比读文档快。第三查配置文件语法是否正确。.prettierrc如果是 JSON 格式多一个逗号、少一个引号都会导致整个文件解析失败而 Prettier 的行为是静默回退到默认配置不报错。这个设计特别阴险。改用.prettierrc.mjs加上 JSDoc 类型标注能规避大部分问题。第四查文件是否在忽略范围内。被.prettierignore排除的文件格式化操作会被跳过且不给任何提示。用npx prettier --check file单文件验证一下就知道。6.2 常见问题速查表现象可能原因排查与解法保存后文件无变化默认格式化器不是 Prettier检查状态栏切换[vue]默认格式化器格式化结果与配置不符配置文件解析失败静默用默认值输出面板确认实际生效配置改用.mjs格式CI 上--check失败但本地正常行尾符 CRLF/LF 差异配置endOfLine: lf加.gitattributes格式化跑得极慢未排除生成目录补.prettierignore重点是.nuxt、.outputESLint 和 Prettier 互相改风格类规则未关闭引入eslint-config-prettier并放在配置最后提交时钩子不触发simple-git-hooks未安装执行一次pnpm simple-git-hooksTailwind class 顺序没变插件未加载或配置路径错确认plugins数组和tailwindConfig路径模板内容被挤成一行htmlWhitespaceSensitivity取值不当改回css用 CSS 控制间距而非空白字符再补三个不那么常见但真会遇到的现象某个.vue文件格式化后组件行为变了。大概率是template里存在依赖换行的写法比如字符串插值跨行、或者pre标签内的预格式化文本。pre块会被 Prettier 特殊对待但边界情况仍可能出现。解法是用pre配合显式的v-pre或者把那段内容挪到独立的.html文件里。现象格式化后 TypeScript 类型报错。这种情况多半出在对象类型声明的排版上。某些边缘写法下Prettier 的换行策略会让satisfies或条件类型的解析产生歧义。遇到时先确认 Prettier 版本升级到最新小版本通常能解决。现象不同成员格式化出的结果不一样。先查 Prettier 版本是否统一。package.json里别写^3.0.0这种宽松范围锁版本能省掉大量扯皮。用pnpm的话锁文件天然保证一致用npm的话检查package-lock.json是否被提交。6.3 几条不上文档的心得第一条别为了迁就旧代码而放宽规则。见过太多项目把printWidth调到 200理由是历史代码行太长。正确的做法是让 Prettier 一次性把历史代码收拢而不是让规则去适应坏代码。规则一放宽新代码会继续往宽里写问题只会加剧。第二条.prettierrc变更要当作架构变更对待。改之前先算一下影响面npx prettier --check .有多少文件会受影响估算一下 diff 行数。超过一千行的改动走分批提交留好.git-blame-ignore-revs记录。第三条别用prettier-ignore注释偷懒。// prettier-ignore能跳过下一个节点的格式化偶尔用一两次没问题比如手工对齐的 ASCII 表格、特殊排版的常量数组但如果一个文件里有五处以上说明那里本来就不该让工具介入把它拆成独立模块比到处加注释更干净。第四条定期检查配置是否还活着。团队扩到十几人之后常见情况是有人为了赶需求临时在eslint.config.mjs里加了规则或者把lint-staged的 pre-commit 注释掉了忘了恢复。我习惯在每个迭代的收尾阶段跑一次pnpm format:check把它当作健康检查的一部分。这个动作成本极低但能拦住大半格式慢慢又乱回去了的问题。最后分享一个我个人用下来觉得最省心的组合.prettierrc.mjs写配置有类型提示.prettierignore划死边界 eslint-config-prettier放在配置末尾 simple-git-hooks跑lint-staged CI 上加一道format:check。这五件套配齐之后团队里几乎不会再有人因为格式问题来回返工代码评审也能专注在真正值得讨论的地方。