开头先直说结论Prettier 不生效这事和 Cursor 这个编辑器本身的关系往往比你想的要大。你很可能已经经历过这种场景——扩展装了配置写了甚至重启了好几遍 Cursor结果按下保存键代码纹丝不动或者格式化的结果和一坨乱码没有本质区别。我过去小半年一直用 Cursor 写前端项目从 React 到 Vue 3 TypeScript 再到带 Pinia 和 Vue Router 的中后台项目Prettier 不生效这个问题我踩了不下十次坑最后把“排查路径”固化成了一个固定流程基本五分钟内能定位到根因。先说清楚这篇文章适合谁正在使用 Cursor 的开发者不管你是从 VSCode 迁移过来的老手还是刚接触 AI 编辑器的前端新手只要你遇到了“保存不格式化”“手动格式化没反应”“格式化结果和配置文件对不上”这类问题这篇文章都能给你一张完整的排查地图。我会先帮你把“不生效”具体化再按优先级逐个拆解从编辑器设置、Cursor 专属的 AI 格式化坑到 .prettierrc 配置文件的加载机制最后是 ESLint、Vite、Vue 等工具链的联动问题。每一层我都会附上实际验证过的操作步骤和配置示例你跟着走一遍大概率能解决。另外说句题外话最近搜 Cursor 相关热词时发现很多人在问“cursor 中文怎么设置”“cursor 怎么使用”这类基础问题。这类问题你直接在 Cursor 左下角齿轮进入设置搜索 language 就能改界面语言。但这篇文章不讲那个我们专注讲代码格式化这一个非常具体、又非常影响开发体验的痛点。1. 先别急着重装把“不生效”这件事具体化1.1 你遇到的到底是哪一种“不生效”很多人在群里问“Prettier 不生效怎么办”但“不生效”其实是一个模糊感极强的词。我见过至少五种完全不同的情况它们对应的排查方向截然不同保存时不自动格式化文件能手动格式化但 Ctrl/CmdS 保存后代码没有任何变化。手动格式化也没反应在 Cursor 里执行 ShiftAltF 或右键 Format Document界面左下角可能弹出“There is no formatter”之类的提示也可能完全无响应。格式化了但风格不对比如你没有把引号改成单引号没有去掉分号或者 tab 宽度还是默认的 2 空格这说明 Prettier 在执行但它读到的配置不是你以为的那份。部分文件类型不生效.js/.ts 文件正常但 .vue 文件格式化后布局乱了或者模板部分根本没有被处理。被 AI 功能“截胡”保存后代码确实动了但改动结果看起来像是 AI 自动调整过的而不是 Prettier 的风格。这种情况在 Cursor 里尤其常见。以上五种严格来说只有前两种算“完全不生效”后面三种属于“配置错位”或“格式化器抢占”。你只有先定位到自己属于哪一种才不会到处乱试。建议你现在打开一个乱格式的测试文件随便敲几行变量声明加上多余的括号和分号保存一次然后仔细观察是没有任何变化还是变了但和预期不同。这个简单的实验能帮你确认问题层级。1.2 五分钟快速定位问题层级实际操作里我一般会先做一个“最小化验证”新建一个临时文件夹只放两个文件——一个 test.js里面写点明显会被 Prettier 重排的代码一个 package.json里面用prettier字段声明最简单的规则比如{ semi: false, singleQuote: true }。然后在 Cursor 中打开这个 test.js手动执行一次格式化命令观察结果。如果此时格式化正常说明 Cursor 本身、Prettier 扩展、以及基本配置链路没问题问题几乎肯定出在你的项目里——可能是配置文件被其他目录层级覆盖了也可能是 .prettierignore 把目录忽略了或者和 ESLint 冲突。如果在这个最小环境里依然不生效那问题就集中在你的 Cursor 全局设置、扩展安装状态或 Cursor 自身版本上。这个实验每次都能帮我省下大量瞎折腾的时间。请你一定先跑一下这个最小化验证再往下看不然很容易被各种帖子带偏方向。2. 第一梯队排查扩展和编辑器设置2.1 扩展真的装了吗装了又真的加载了吗我知道这句话听起来像废话但我在 Cursor 里排查过非常多“不生效”的案例其中有相当一部分人装的不是官方 Prettier 扩展而是某个名称里带 “Prettier” 的第三方扩展或者同时装了好几个格式化相关扩展。比如在扩展市场搜 “prettier”你会看到Prettier - Code formatter作者 esbenp.prettier-vscode官方发行版认准这个Prettier Code formatter 这类名称绕来绕去的第三方扩展某些集合包extension pack里自带的 Prettier 版本多扩展共存最大的问题是Cursor 在解析默认格式化器时可能命中错误的扩展 ID导致你明明在设置里写了某个格式化器名称实际调用的却是另一个。我建议你把格式化相关的扩展清理一下只保留官方版。方法很简单在左侧扩展面板搜索installed prettier把不是esbenp.prettier-vscode的都卸载掉。另一个关键点是扩展装好了也不代表它在当前工作区被启用。Cursor 支持工作区级别的扩展禁用如果你之前在某次弹窗中点了“Disable for Workspace”扩展图标会变成灰色右下角还可能有一个黄色的 “受限模式” 提示。这种情况在 VSCode 和 Cursor 里都有可能发生而且特别隐蔽。排查时记得点开 Cursor 顶部菜单栏的 “View” → “Extensions”确认 Prettier 扩展状态是启用且可用的。2.2 默认格式化器设置百分之八十的问题都出在这里排除了扩展问题之后下一步就去设置搜索框里搜defaultFormatter然后检查Editor: Default Formatter的值。这里有个很大的误区很多人只在全局设置了默认格式化器是 Prettier但当前项目的工作区设置.vscode/settings.json里没有设置甚至被某个配置覆盖成了 null。Cursor 读取设置时项目级设置优先级高于用户级设置所以一旦项目的 .vscode/settings.json 里写了editor.defaultFormatter: null或editor.defaultFormatter: vscode.typescript-language-features全局的 Prettier 设置就不会生效。更隐蔽的是语言级别的配置。比如你全局设了 Prettier但项目里或用户设置里针对[typescript]语言单独指定了别的格式化器。Cursor 的配置继承逻辑和 VSCode 基本一致语言特定设置会覆盖通用设置。我推荐的做法是不管全局还是项目级都对常用语言显式指定 Prettier示例配置如下{ editor.formatOnSave: true, editor.defaultFormatter: esbenp.prettier-vscode, [javascript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [typescript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [json]: { editor.defaultFormatter: esbenp.prettier-vscode }, [vue]: { editor.defaultFormatter: esbenp.prettier-vscode }, [html]: { editor.defaultFormatter: esbenp.prettier-vscode } }注意我写了[typescript]、[vue]、[html]等语言级别配置是因为Cursor 在部分版本里把某些语言的默认格式器指向了自带的 TypeScript 格式化器这在 TS 项目里尤其容易触发“保存无效”的情况。手动指定 Prettier 是最一劳永逸的做法。2.3 什么情况下 formatOnSave 会失灵设置里搜索formatOnSave确保它处于勾选状态。但即使你勾选了仍有三类情况会导致保存时格式化不触发没有默认格式化器Cursor 在保存前会确认当前语言是否存在可用的默认格式化器如果它认为没有就直接跳过格式化步骤。这也是为什么我强调要设置editor.defaultFormatter两者必须同时满足。文件被 .prettierignore 忽略了Prettier 扩展在保存事件触发时会先检查文件是否在 ignore 规则内如果在它会静默跳过。“静默”意味着没有任何提示你完全感觉不到发生了什么。后面我专门讲 .prettierignore 这个坑。formatOnSave被工作区设置覆盖你以为你开了但项目里有人或者某个脚手架把editor.formatOnSave: false写进了 .vscode/settings.json。遇到这种情况你需要在设置面板看到右上角出现“工作区”选项卡检查当前作用域下到底是哪个值。排查这一层级时最快的判断方法是打开命令面板Ctrl/CmdShiftP输入 “Format Document” 并手动执行。如果手动能格式化说明格式化器链路正常问题只出在 formatOnSave 的触发条件上如果手动也不行那就继续往下看 Cursor 特有的一些问题。3. Cursor 特有的坑AI 能力与格式化器打架3.1 Cursor 自己的 “format” 动作可能不是 Prettier如果你以前用 VSCode 很顺手一换到 Cursor 就发现格式化行为诡异问题往往出在Cursor 对 “格式化文档” 动作做了一层自己的处理。Cursor 基于 VSCode 二次开发但它在某些菜单项里注册了自带的格式化逻辑或者说对 “Format Document” 命令做了包装。在某些版本中即使你设置了默认格式化器为 Prettier执行格式化时仍然可能触发 Cursor 内置的格式化器比如它自己的 TypeScript 格式化服务导致输出风格和 Prettier 规则不一致。怎么判断当前格式化到底是谁在执行最直接的方法是看 Cursor 的输出日志。打开“查看”菜单 → “输出面板”Output在下拉菜单里选择 “Prettier” 或 “Log (Window)”然后手动格式化一个文件观察输出的日志内容。如果日志里有类似 “Formatting completed” 且来自 Prettier 扩展说明调用的是 Prettier如果日志里没有任何 Prettier 相关输出但代码却变了那你触发的大概率是别的格式化器。针对这个情况我建议在命令面板中使用“Format Document With...”格式化文档为…这个命令它会列出当前文件所有可用的格式化器你明确选择 Prettier 后还可以接着点击 “Configure Default Formatter” 将它设为默认。这个命令比直接在 settings 里改更有优势它会根据当前激活的语言自动写入正确的语言级配置不会出现你手动写配置时把语言标识写错的情况。3.2 自动保存格式化后AI Tab 补全把代码搞乱了Cursor 最核心的体验是 Tab 补全它能够预测你要写的整段代码一次性输出大量内容。这个功能本身很爽但随之而来一个非常微妙的坑Tab 补全生成的代码风格往往不完全符合 Prettier 规则。比如 AI 生成的 JSX 可能自带 4 空格缩进可能在不该加分号的地方加了分号更常见的是对象属性多行排列、换行位置混乱。如果你开启了 formatOnSave保存时 Prettier 会把 AI 生成的代码重新排版最终结果是好的。但问题在于很多人用 Cursor 时的默认动作是Tab 接受 AI 补全 → 顺手敲一行 → 继续让 AI 补下一段中间不保存。等到最后保存时可能会因为某种原因比如 formatOnSave 被关了或者代码块包含了语法错误导致格式化没有触发于是 AI 生成的糟糕格式就留在文件里了。你会觉得“Prettier 没生效”但本质是你从来没真正保存过Prettier 没机会执行。我的习惯是接受 Tab 补全后立刻按一次 CmdS。这样做有两个好处一是让 Prettier 及时纠正 AI 输出的格式避免错误风格在文件里越积越多二是让后续 AI 补全参考的是已经格式化过的干净上下文AI 的续写质量也会更高。实测下来这个习惯能把“代码变乱”的问题减少一大半。3.3 CommandK 等 AI 编辑命令会绕过 Prettier 吗Cursor 的 CmdKAI 编辑和 CmdLAI 对话在修改代码时不会主动调用 Prettier。它们会直接把生成结果写入文件这就是为什么你让 AI 改完一段逻辑后整个文件的格式可能变得面目全非——而不是 Prettier 失效。对比之下VSCode 原生没有这种嵌入式的 AI 编辑器所以这个问题是 Cursor 使用者特有的体验。要处理这个问题有两个思路一个是“事后格式化”流AI 修改完代码后手动执行一次格式化命令或者保存一次前提是 formatOnSave 开启。另一个是“事前约束”流在项目根目录写一个.cursorrules文件明确告诉 AI 遵守项目已有的代码风格比如“Always use single quotes, no semicolons, indent with 2 spaces, and follow Prettier rules.” 这会显著降低 AI 输出的“野生格式”出现频率。.cursorrules是 Cursor 非常实用的一个功能我强烈建议所有团队项目都维护一份。它不直接解决 Prettier 的触发问题但能从源头上减少 AI 产生的格式噪音让 Prettier 的格式化结果更稳定这个是经验之谈。4. 配置文件层面的工程化隐患4.1 Prettier 找的是哪一份配置文件当 Prettier 运行时它需要决定使用什么规则。它的默认查找逻辑是从当前文件所在目录开始向上递归寻找配置文件找到最近的一份就停且只认.prettierrc、.prettierrc.json、.prettierrc.yml、.prettierrc.js、.prettier.config.js这些文件名或者 package.json 里的prettier字段。这个机制会带来几个容易忽略的坑你的项目是 monorepo 或者多层目录结构可能某个子目录下比如src/components/放了一份旧的 .prettierrc那么该目录下的文件格式会使用这份“局部配置”即使根目录有一份你认为的全局配置。如果你改了根目录配置却发现子目录不生效大概率就是这个原因。工作区是多根目录multi-root workspaceCursor 支持把多个文件夹加入同一个工作区此时每根目录的配置是独立解析的不会相互继承。你在某个项目里写了配置另一个项目目录下完全不受影响这其实符合预期但很多人把它误认为 bug。配置文件名写错Prettier 扩展对配置文件的识别比较严格.prettierrc.yaml可以但.prettierrc.txt不行.prettierrc.js需要模块导出对象如果导出格式错误扩展会在输出日志里报错但界面不一定弹提示。排查配置问题时我建议你直接在项目根目录执行命令行验证npx prettier --find-config-path src/你的文件.ts或者npx prettier --check src/**/*.ts。这样能看到 Prettier 实际找到的配置路径比在编辑器里瞎猜高效得多。4.2 .prettierignore 和 EditorConfig 的优先级问题formatOnSave失效的另一个高频原因是.prettierignore文件存在且把目标目录或文件忽略了。我在接手一个维护很久的项目时就遇到过.prettierignore里写着dist/、node_modules/这类目录但项目里却把src也写了进去的情况。当时的表现是保存 src 下的所有文件Prettier 都没有任何反应也不报警告。因为 Prettier 的设计就是“被忽略的文件不做任何处理”静默跳过。检查方法打开项目根目录的.prettierignore看看是否有src/、**/*.ts这类过于宽泛的规则也可以使用命令面板里的 “Prettier: Show Ignored Files” 或者直接看 Prettier 输出日志中是否出现 “Ignored” 字样。另一样东西是.editorconfig。Prettier 官方扩展会读取 .editorconfig 来推断缩进风格、行尾符等基础配置。如果 .editorconfig 里定义了indent_size 4而你的 .prettierrc 里写的是tabWidth: 2最终生效的可能是 4因为.editorconfig的优先级在 Prettier 扩展中更高。这一点很多人在网上对线“为什么我的 prettier 配置没生效”时根本没意识到。解决方案是让两者的缩进、行尾符保持一致或者在 .editorconfig 里关闭相关设置indent_size unset保证 Prettier 完全听 .prettierrc 的。4.3 多版本 Prettier 与依赖安装的坑Prettier 的格式化结果在不同大版本之间可能差异很大。比如 Prettier 2.x 和 3.x 在处理一些语法比如satisfies、某些 TS 泛型写法时的输出风格就有差别。如果你在项目里通过 npm 安装了 Prettier 3.x而 Cursor 扩展自带或依赖的是 2.x 版本那么保存文件时扩展可能优先调用它自己内置的 Prettier 实例格式化的结果自然和你在命令行里用npx prettier得到的输出不一致。更常见的情况是项目里根本没有把 Prettier 安装为本地依赖Prettier 扩展只能使用它内置的版本而内置版本可能与项目 .prettierrc 里的某些配置项不兼容比如某个插件、某个较新的选项导致配置文件被忽略或直接报错。我的建议是在所有规模稍大的前端项目里都把 Prettier 作为 devDependency 安装npm install -D prettier然后在 Cursor 的设置里搜索prettier.requireConfig或prettier.prettierPath将prettier.prettierPath指向项目本地的 node_modules/.bin/prettier 路径。这样扩展和命令行使用的就是同一份 Prettier行为完全一致不会再出现“编辑器里一个样命令行另一个样”的诡异情况。如果你用 pnpm路径一般是node_modules/.pnpm/prettier版本号/node_modules/prettier你可以直接在设置里填node_modules/.bin/prettierCursor 通常能正确解析。5. 与 ESLint、Vue/React 等工具链联动的特殊场景5.1 ESLint 和 Prettier 的格式化规则冲突现在稍微正规一点的工程都会集成 ESLint而 ESLint 也自带一些格式化规则比如quotes、semi、indent。当 Prettier 和 ESLint 规则对同一段代码给出不同的预期时如果你同时开启了 “eslint.onSave” 或 “ESLint: Fix all auto-fixable problems on save” 之类的功能就会出现“保存后代码被反复拉扯”的现象Prettier 先格式化然后 ESLint 按自己的规则改一遍或者顺序反过来最终你看到的结果既不是 Prettier 风格也不是 ESLint 风格。这里牵扯到一个业界共识格式化的事交给 Prettier代码质量检查的事交给 ESLint两者不要混着做。具体到工程配置上有两个选项安装eslint-config-prettier关闭 ESLint 里所有与格式化相关的规则让 Prettier 全权负责格式。如果你们团队习惯通过 ESLint 跑格式化那就安装eslint-plugin-prettier把 Prettier 作为一条 ESLint 规则来运行这种情况下理论上可以不装 Prettier 扩展但实际体验不如独立格式化。我自己的推荐是eslint-config-prettier路线同时把 Cursor 的保存动作设置为只触发 Prettier 格式化不让 ESLint 在保存时自动修复。ESLint 留在你手动运行npm run lint或者在 CI 里做检查。这样每种工具各司其职不会再因为两个格式化器的竞争导致“保存一会变单引号一会变双引号”这种哭笑不得的问题。顺带提一句现在很多模板比如 Vite 初始化 Vue 项目时选上的 ESLint Prettier已经自动配好了eslint-config-prettier。如果你是新项目选模板时直接勾选即可如果是老项目检查一下 eslint.config.js 里是否继承了 prettier 相关配置。搜索结果热词里也有“vue router pinia eslint prettier vitest单元测试 这个是选什么”这类问题其实就是让你选择前端工程化配套。大多数情况下选默认推荐组合就行但格式化部分必须保证 Prettier 有最终话语权。5.2 Volar/TypeScript 与 .vue 文件的格式化问题如果你在做 Vue 3 项目还开着VolarVue Language Features或Vue Official扩展那么你会碰到一个非常典型的“部分生效”问题script标签里的 TypeScript 代码保存后正常格式化但template里的 HTML 结构没有任何变化或者反过来。原因是 .vue 文件是一个多语言混合文件格式化器需要安装对应的语言服务才能正确处理。解决办法是在设置里对[vue]语言显式指定默认格式化器为 Prettier我前面给过配置。同时确保 Volar 扩展的 “Vue: Takeover Mode” 或者相关格式化能力不会覆盖 Prettier。如果你发现 template 部分仍然不格式化可以直接在命令面板里执行 “Format Document With...” → 选择 Prettier。如果此时 Prettier 不出现说明 .vue 文件没有被 Prettier 扩展识别为可格式化文件你需要检查 Prettier 扩展是否有针对 Vue 的插件支持。React 项目同样有这个隐患.tsx、.jsx文件的情况稍好但如果你安装了某些额外的 HTML/CSS 格式化扩展比如 Beautify它们可能标记自己支持 JavaScript/TypeScript然后在优先级上把 Prettier 挤下去了。我的原则是整个项目里只保留 Prettier 一个格式化器凡是名字里带 “Formatter” 且不认识的扩展一律禁用这样能减少 80% 的同类问题。5.3 团队项目里别忽视共享配置与个人配置的覆盖关系团队协作项目中.vscode/settings.json通常会被提交进仓库里作为统一的编辑器规范。如果你发现 Prettier 不生效而此时仓库里存在.vscode/settings.json并且内部写了一些奇怪的设置比如editor.formatOnSave: false、editor.defaultFormatter: vscode.html-language-features那这个文件就是罪魁祸首。它会被所有团队成员共享覆盖本地配置因此你在 Cursor 设置里怎么改全局设置都没用因为在项目级设置优先的规则下仓库里的配置才是最终生效的。处理方式有两种如果这个项目是你自己维护的直接把 .vscode/settings.json 改正确并提交如果项目里那份配置已经过时或者存在恶意/错误的配置建议先在本地覆盖测试然后与团队成员沟通修正。类似地有些项目还会在.vscode/extensions.json里推荐扩展但推荐不代表自动禁用所以可以忽略它专心检查 settings.json 即可。还有一个小点多个配置文件共存时用户级、工作组级、项目级的优先级你要记牢——项目级 工作组级 用户级。在排查时永远先打开项目根目录的 .vscode/settings.json用排除法确认它没有“捣乱”。6. 排查命令、速查表与我的推荐配置6.1 几条真正有用的调试命令和操作除了前面零零散散提到的命令我再集中整理一份排查 Prettier 问题时最高频使用的操作清单按顺序执行基本能覆盖所有已知问题命令面板 → Format Document格式化文档手动触发一次格式化判断格式化器链路是否正常。命令面板 → Format Document With...格式化文档为…手动选择 Prettier并设置默认格式化器。命令面板 → 输入 “Prettier: Show Output” / 打开输出面板选择 “Prettier”查看 Prettier 扩展运行日志确认是否报错、是否找到配置、是否忽略了文件。终端执行npx prettier --check src/**/*.ts绕过编辑器直接验证 Prettier 本身和配置文件是否工作正常。终端执行npx prettier --write src/某文件.ts如果终端能正确格式化说明问题只和编辑器扩展/触发设置相关如果终端也报错那就是依赖安装、配置文件或 Prettier 版本的问题。npx prettier --find-config-path src/某文件.ts判断当前文件实际命中了哪个配置文件特别适合 monorepo 和多配置项目。6.2 Cursor 的全局和项目设置里我建议检查的 10 项下面这张表是我处理 Cursor Prettier 问题时最终沉淀下来的检查清单。每一项我都标出了推荐值你可以直接对照自己的设置排查设置项查找/写入位置推荐值说明editor.formatOnSave设置 → 文本编辑器 → 格式化勾选保存时自动格式化的总开关editor.defaultFormatter设置 → 文本编辑器 → 格式化esbenp.prettier-vscode全局默认格式化器[typescript]/[javascript]/[vue]的 formatter设置 → 语言特定设置esbenp.prettier-vscode防止语言级覆盖prettier.requireConfig设置 → 扩展 → Prettier建议false新项目建议 true是否要求必须有配置文件才格式化设 true 后无配置则静默跳过prettier.prettierPath设置 → 扩展 → Prettier本地依赖路径如node_modules/prettier确保和命令行使用同一版本 Prettierprettier.configPath设置 → 扩展 → Prettier留空自动查找或指定绝对路径显式指定配置文件位置适合 monorepoESLint 保存时格式化设置 → 扩展 → ESLint建议关闭eslint.codeActionsOnSave避免 ESLint 和 Prettier 抢格式化权.vscode/settings.json项目根目录内容与上述推荐值一致项目级优先级最高先检查.prettierignore项目根目录确认没有误伤 src 目录被忽略的文件不格式化.editorconfig项目根目录与 .prettierrc 的缩进/行尾符一致确保不会覆盖 Prettier 配置6.3 一劳永逸的推荐配置最后我把目前我所有项目都在用的的一套配置完整放出来你可以直接抄走根据项目情况删减。项目根目录.vscode/settings.json{ editor.formatOnSave: true, editor.defaultFormatter: esbenp.prettier-vscode, editor.codeActionsOnSave: { source.fixAll.eslint: explicit }, [javascript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [typescript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [javascriptreact]: { editor.defaultFormatter: esbenp.prettier-vscode }, [typescriptreact]: { editor.defaultFormatter: esbenp.prettier-vscode }, [vue]: { editor.defaultFormatter: esbenp.prettier-vscode }, [json]: { editor.defaultFormatter: esbenp.prettier-vscode }, prettier.requireConfig: false, prettier.prettierPath: ./node_modules/prettier }项目根目录.prettierrc基础示例{ semi: false, singleQuote: true, printWidth: 100, tabWidth: 2, trailingComma: es5, arrowParens: always, endOfLine: lf }项目根目录.editorconfig注意保持风格一致root true [*] charset utf-8 indent_style space indent_size 2 end_of_line lf insert_final_newline true trim_trailing_whitespace true这套配置的好处是保存时只让 Prettier 负责格式化ESLint 只在必要时通过 codeActionsOnSave 修复可自动修复的问题而且两者依赖的缩进、引号、分号规则完全一致不会再出现互相打架的结果。如果你用的是 Vue 项目建议把prettier.requireConfig始终保持为true并且确保根目录有 .prettierrc 文件这样团队里每个人拿到代码后看到的格式都是一样的不会出现“我本地格式化完 commit你 pull 下来再格式化又变一遍”的噩梦。我的个人经验是所有这类“不生效”问题绝大多数都不是 Cursor 的 bug而是设置优先级和工具职责边界不清导致的。Cursor 作为 AI 编辑器它自己的能力很强但它同时也继承了 VSCode 那套完善的配置体系你得主动告诉它“格式化的事情不要自己管交给 Prettier”。只要把这条规则在全局和项目层面都写明之后再安装 AI 扩展、切换项目环境基本就不会再遇到格式化失效的问题了。
Cursor中Prettier不生效？五分钟定位根因的排查指南
开头先直说结论Prettier 不生效这事和 Cursor 这个编辑器本身的关系往往比你想的要大。你很可能已经经历过这种场景——扩展装了配置写了甚至重启了好几遍 Cursor结果按下保存键代码纹丝不动或者格式化的结果和一坨乱码没有本质区别。我过去小半年一直用 Cursor 写前端项目从 React 到 Vue 3 TypeScript 再到带 Pinia 和 Vue Router 的中后台项目Prettier 不生效这个问题我踩了不下十次坑最后把“排查路径”固化成了一个固定流程基本五分钟内能定位到根因。先说清楚这篇文章适合谁正在使用 Cursor 的开发者不管你是从 VSCode 迁移过来的老手还是刚接触 AI 编辑器的前端新手只要你遇到了“保存不格式化”“手动格式化没反应”“格式化结果和配置文件对不上”这类问题这篇文章都能给你一张完整的排查地图。我会先帮你把“不生效”具体化再按优先级逐个拆解从编辑器设置、Cursor 专属的 AI 格式化坑到 .prettierrc 配置文件的加载机制最后是 ESLint、Vite、Vue 等工具链的联动问题。每一层我都会附上实际验证过的操作步骤和配置示例你跟着走一遍大概率能解决。另外说句题外话最近搜 Cursor 相关热词时发现很多人在问“cursor 中文怎么设置”“cursor 怎么使用”这类基础问题。这类问题你直接在 Cursor 左下角齿轮进入设置搜索 language 就能改界面语言。但这篇文章不讲那个我们专注讲代码格式化这一个非常具体、又非常影响开发体验的痛点。1. 先别急着重装把“不生效”这件事具体化1.1 你遇到的到底是哪一种“不生效”很多人在群里问“Prettier 不生效怎么办”但“不生效”其实是一个模糊感极强的词。我见过至少五种完全不同的情况它们对应的排查方向截然不同保存时不自动格式化文件能手动格式化但 Ctrl/CmdS 保存后代码没有任何变化。手动格式化也没反应在 Cursor 里执行 ShiftAltF 或右键 Format Document界面左下角可能弹出“There is no formatter”之类的提示也可能完全无响应。格式化了但风格不对比如你没有把引号改成单引号没有去掉分号或者 tab 宽度还是默认的 2 空格这说明 Prettier 在执行但它读到的配置不是你以为的那份。部分文件类型不生效.js/.ts 文件正常但 .vue 文件格式化后布局乱了或者模板部分根本没有被处理。被 AI 功能“截胡”保存后代码确实动了但改动结果看起来像是 AI 自动调整过的而不是 Prettier 的风格。这种情况在 Cursor 里尤其常见。以上五种严格来说只有前两种算“完全不生效”后面三种属于“配置错位”或“格式化器抢占”。你只有先定位到自己属于哪一种才不会到处乱试。建议你现在打开一个乱格式的测试文件随便敲几行变量声明加上多余的括号和分号保存一次然后仔细观察是没有任何变化还是变了但和预期不同。这个简单的实验能帮你确认问题层级。1.2 五分钟快速定位问题层级实际操作里我一般会先做一个“最小化验证”新建一个临时文件夹只放两个文件——一个 test.js里面写点明显会被 Prettier 重排的代码一个 package.json里面用prettier字段声明最简单的规则比如{ semi: false, singleQuote: true }。然后在 Cursor 中打开这个 test.js手动执行一次格式化命令观察结果。如果此时格式化正常说明 Cursor 本身、Prettier 扩展、以及基本配置链路没问题问题几乎肯定出在你的项目里——可能是配置文件被其他目录层级覆盖了也可能是 .prettierignore 把目录忽略了或者和 ESLint 冲突。如果在这个最小环境里依然不生效那问题就集中在你的 Cursor 全局设置、扩展安装状态或 Cursor 自身版本上。这个实验每次都能帮我省下大量瞎折腾的时间。请你一定先跑一下这个最小化验证再往下看不然很容易被各种帖子带偏方向。2. 第一梯队排查扩展和编辑器设置2.1 扩展真的装了吗装了又真的加载了吗我知道这句话听起来像废话但我在 Cursor 里排查过非常多“不生效”的案例其中有相当一部分人装的不是官方 Prettier 扩展而是某个名称里带 “Prettier” 的第三方扩展或者同时装了好几个格式化相关扩展。比如在扩展市场搜 “prettier”你会看到Prettier - Code formatter作者 esbenp.prettier-vscode官方发行版认准这个Prettier Code formatter 这类名称绕来绕去的第三方扩展某些集合包extension pack里自带的 Prettier 版本多扩展共存最大的问题是Cursor 在解析默认格式化器时可能命中错误的扩展 ID导致你明明在设置里写了某个格式化器名称实际调用的却是另一个。我建议你把格式化相关的扩展清理一下只保留官方版。方法很简单在左侧扩展面板搜索installed prettier把不是esbenp.prettier-vscode的都卸载掉。另一个关键点是扩展装好了也不代表它在当前工作区被启用。Cursor 支持工作区级别的扩展禁用如果你之前在某次弹窗中点了“Disable for Workspace”扩展图标会变成灰色右下角还可能有一个黄色的 “受限模式” 提示。这种情况在 VSCode 和 Cursor 里都有可能发生而且特别隐蔽。排查时记得点开 Cursor 顶部菜单栏的 “View” → “Extensions”确认 Prettier 扩展状态是启用且可用的。2.2 默认格式化器设置百分之八十的问题都出在这里排除了扩展问题之后下一步就去设置搜索框里搜defaultFormatter然后检查Editor: Default Formatter的值。这里有个很大的误区很多人只在全局设置了默认格式化器是 Prettier但当前项目的工作区设置.vscode/settings.json里没有设置甚至被某个配置覆盖成了 null。Cursor 读取设置时项目级设置优先级高于用户级设置所以一旦项目的 .vscode/settings.json 里写了editor.defaultFormatter: null或editor.defaultFormatter: vscode.typescript-language-features全局的 Prettier 设置就不会生效。更隐蔽的是语言级别的配置。比如你全局设了 Prettier但项目里或用户设置里针对[typescript]语言单独指定了别的格式化器。Cursor 的配置继承逻辑和 VSCode 基本一致语言特定设置会覆盖通用设置。我推荐的做法是不管全局还是项目级都对常用语言显式指定 Prettier示例配置如下{ editor.formatOnSave: true, editor.defaultFormatter: esbenp.prettier-vscode, [javascript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [typescript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [json]: { editor.defaultFormatter: esbenp.prettier-vscode }, [vue]: { editor.defaultFormatter: esbenp.prettier-vscode }, [html]: { editor.defaultFormatter: esbenp.prettier-vscode } }注意我写了[typescript]、[vue]、[html]等语言级别配置是因为Cursor 在部分版本里把某些语言的默认格式器指向了自带的 TypeScript 格式化器这在 TS 项目里尤其容易触发“保存无效”的情况。手动指定 Prettier 是最一劳永逸的做法。2.3 什么情况下 formatOnSave 会失灵设置里搜索formatOnSave确保它处于勾选状态。但即使你勾选了仍有三类情况会导致保存时格式化不触发没有默认格式化器Cursor 在保存前会确认当前语言是否存在可用的默认格式化器如果它认为没有就直接跳过格式化步骤。这也是为什么我强调要设置editor.defaultFormatter两者必须同时满足。文件被 .prettierignore 忽略了Prettier 扩展在保存事件触发时会先检查文件是否在 ignore 规则内如果在它会静默跳过。“静默”意味着没有任何提示你完全感觉不到发生了什么。后面我专门讲 .prettierignore 这个坑。formatOnSave被工作区设置覆盖你以为你开了但项目里有人或者某个脚手架把editor.formatOnSave: false写进了 .vscode/settings.json。遇到这种情况你需要在设置面板看到右上角出现“工作区”选项卡检查当前作用域下到底是哪个值。排查这一层级时最快的判断方法是打开命令面板Ctrl/CmdShiftP输入 “Format Document” 并手动执行。如果手动能格式化说明格式化器链路正常问题只出在 formatOnSave 的触发条件上如果手动也不行那就继续往下看 Cursor 特有的一些问题。3. Cursor 特有的坑AI 能力与格式化器打架3.1 Cursor 自己的 “format” 动作可能不是 Prettier如果你以前用 VSCode 很顺手一换到 Cursor 就发现格式化行为诡异问题往往出在Cursor 对 “格式化文档” 动作做了一层自己的处理。Cursor 基于 VSCode 二次开发但它在某些菜单项里注册了自带的格式化逻辑或者说对 “Format Document” 命令做了包装。在某些版本中即使你设置了默认格式化器为 Prettier执行格式化时仍然可能触发 Cursor 内置的格式化器比如它自己的 TypeScript 格式化服务导致输出风格和 Prettier 规则不一致。怎么判断当前格式化到底是谁在执行最直接的方法是看 Cursor 的输出日志。打开“查看”菜单 → “输出面板”Output在下拉菜单里选择 “Prettier” 或 “Log (Window)”然后手动格式化一个文件观察输出的日志内容。如果日志里有类似 “Formatting completed” 且来自 Prettier 扩展说明调用的是 Prettier如果日志里没有任何 Prettier 相关输出但代码却变了那你触发的大概率是别的格式化器。针对这个情况我建议在命令面板中使用“Format Document With...”格式化文档为…这个命令它会列出当前文件所有可用的格式化器你明确选择 Prettier 后还可以接着点击 “Configure Default Formatter” 将它设为默认。这个命令比直接在 settings 里改更有优势它会根据当前激活的语言自动写入正确的语言级配置不会出现你手动写配置时把语言标识写错的情况。3.2 自动保存格式化后AI Tab 补全把代码搞乱了Cursor 最核心的体验是 Tab 补全它能够预测你要写的整段代码一次性输出大量内容。这个功能本身很爽但随之而来一个非常微妙的坑Tab 补全生成的代码风格往往不完全符合 Prettier 规则。比如 AI 生成的 JSX 可能自带 4 空格缩进可能在不该加分号的地方加了分号更常见的是对象属性多行排列、换行位置混乱。如果你开启了 formatOnSave保存时 Prettier 会把 AI 生成的代码重新排版最终结果是好的。但问题在于很多人用 Cursor 时的默认动作是Tab 接受 AI 补全 → 顺手敲一行 → 继续让 AI 补下一段中间不保存。等到最后保存时可能会因为某种原因比如 formatOnSave 被关了或者代码块包含了语法错误导致格式化没有触发于是 AI 生成的糟糕格式就留在文件里了。你会觉得“Prettier 没生效”但本质是你从来没真正保存过Prettier 没机会执行。我的习惯是接受 Tab 补全后立刻按一次 CmdS。这样做有两个好处一是让 Prettier 及时纠正 AI 输出的格式避免错误风格在文件里越积越多二是让后续 AI 补全参考的是已经格式化过的干净上下文AI 的续写质量也会更高。实测下来这个习惯能把“代码变乱”的问题减少一大半。3.3 CommandK 等 AI 编辑命令会绕过 Prettier 吗Cursor 的 CmdKAI 编辑和 CmdLAI 对话在修改代码时不会主动调用 Prettier。它们会直接把生成结果写入文件这就是为什么你让 AI 改完一段逻辑后整个文件的格式可能变得面目全非——而不是 Prettier 失效。对比之下VSCode 原生没有这种嵌入式的 AI 编辑器所以这个问题是 Cursor 使用者特有的体验。要处理这个问题有两个思路一个是“事后格式化”流AI 修改完代码后手动执行一次格式化命令或者保存一次前提是 formatOnSave 开启。另一个是“事前约束”流在项目根目录写一个.cursorrules文件明确告诉 AI 遵守项目已有的代码风格比如“Always use single quotes, no semicolons, indent with 2 spaces, and follow Prettier rules.” 这会显著降低 AI 输出的“野生格式”出现频率。.cursorrules是 Cursor 非常实用的一个功能我强烈建议所有团队项目都维护一份。它不直接解决 Prettier 的触发问题但能从源头上减少 AI 产生的格式噪音让 Prettier 的格式化结果更稳定这个是经验之谈。4. 配置文件层面的工程化隐患4.1 Prettier 找的是哪一份配置文件当 Prettier 运行时它需要决定使用什么规则。它的默认查找逻辑是从当前文件所在目录开始向上递归寻找配置文件找到最近的一份就停且只认.prettierrc、.prettierrc.json、.prettierrc.yml、.prettierrc.js、.prettier.config.js这些文件名或者 package.json 里的prettier字段。这个机制会带来几个容易忽略的坑你的项目是 monorepo 或者多层目录结构可能某个子目录下比如src/components/放了一份旧的 .prettierrc那么该目录下的文件格式会使用这份“局部配置”即使根目录有一份你认为的全局配置。如果你改了根目录配置却发现子目录不生效大概率就是这个原因。工作区是多根目录multi-root workspaceCursor 支持把多个文件夹加入同一个工作区此时每根目录的配置是独立解析的不会相互继承。你在某个项目里写了配置另一个项目目录下完全不受影响这其实符合预期但很多人把它误认为 bug。配置文件名写错Prettier 扩展对配置文件的识别比较严格.prettierrc.yaml可以但.prettierrc.txt不行.prettierrc.js需要模块导出对象如果导出格式错误扩展会在输出日志里报错但界面不一定弹提示。排查配置问题时我建议你直接在项目根目录执行命令行验证npx prettier --find-config-path src/你的文件.ts或者npx prettier --check src/**/*.ts。这样能看到 Prettier 实际找到的配置路径比在编辑器里瞎猜高效得多。4.2 .prettierignore 和 EditorConfig 的优先级问题formatOnSave失效的另一个高频原因是.prettierignore文件存在且把目标目录或文件忽略了。我在接手一个维护很久的项目时就遇到过.prettierignore里写着dist/、node_modules/这类目录但项目里却把src也写了进去的情况。当时的表现是保存 src 下的所有文件Prettier 都没有任何反应也不报警告。因为 Prettier 的设计就是“被忽略的文件不做任何处理”静默跳过。检查方法打开项目根目录的.prettierignore看看是否有src/、**/*.ts这类过于宽泛的规则也可以使用命令面板里的 “Prettier: Show Ignored Files” 或者直接看 Prettier 输出日志中是否出现 “Ignored” 字样。另一样东西是.editorconfig。Prettier 官方扩展会读取 .editorconfig 来推断缩进风格、行尾符等基础配置。如果 .editorconfig 里定义了indent_size 4而你的 .prettierrc 里写的是tabWidth: 2最终生效的可能是 4因为.editorconfig的优先级在 Prettier 扩展中更高。这一点很多人在网上对线“为什么我的 prettier 配置没生效”时根本没意识到。解决方案是让两者的缩进、行尾符保持一致或者在 .editorconfig 里关闭相关设置indent_size unset保证 Prettier 完全听 .prettierrc 的。4.3 多版本 Prettier 与依赖安装的坑Prettier 的格式化结果在不同大版本之间可能差异很大。比如 Prettier 2.x 和 3.x 在处理一些语法比如satisfies、某些 TS 泛型写法时的输出风格就有差别。如果你在项目里通过 npm 安装了 Prettier 3.x而 Cursor 扩展自带或依赖的是 2.x 版本那么保存文件时扩展可能优先调用它自己内置的 Prettier 实例格式化的结果自然和你在命令行里用npx prettier得到的输出不一致。更常见的情况是项目里根本没有把 Prettier 安装为本地依赖Prettier 扩展只能使用它内置的版本而内置版本可能与项目 .prettierrc 里的某些配置项不兼容比如某个插件、某个较新的选项导致配置文件被忽略或直接报错。我的建议是在所有规模稍大的前端项目里都把 Prettier 作为 devDependency 安装npm install -D prettier然后在 Cursor 的设置里搜索prettier.requireConfig或prettier.prettierPath将prettier.prettierPath指向项目本地的 node_modules/.bin/prettier 路径。这样扩展和命令行使用的就是同一份 Prettier行为完全一致不会再出现“编辑器里一个样命令行另一个样”的诡异情况。如果你用 pnpm路径一般是node_modules/.pnpm/prettier版本号/node_modules/prettier你可以直接在设置里填node_modules/.bin/prettierCursor 通常能正确解析。5. 与 ESLint、Vue/React 等工具链联动的特殊场景5.1 ESLint 和 Prettier 的格式化规则冲突现在稍微正规一点的工程都会集成 ESLint而 ESLint 也自带一些格式化规则比如quotes、semi、indent。当 Prettier 和 ESLint 规则对同一段代码给出不同的预期时如果你同时开启了 “eslint.onSave” 或 “ESLint: Fix all auto-fixable problems on save” 之类的功能就会出现“保存后代码被反复拉扯”的现象Prettier 先格式化然后 ESLint 按自己的规则改一遍或者顺序反过来最终你看到的结果既不是 Prettier 风格也不是 ESLint 风格。这里牵扯到一个业界共识格式化的事交给 Prettier代码质量检查的事交给 ESLint两者不要混着做。具体到工程配置上有两个选项安装eslint-config-prettier关闭 ESLint 里所有与格式化相关的规则让 Prettier 全权负责格式。如果你们团队习惯通过 ESLint 跑格式化那就安装eslint-plugin-prettier把 Prettier 作为一条 ESLint 规则来运行这种情况下理论上可以不装 Prettier 扩展但实际体验不如独立格式化。我自己的推荐是eslint-config-prettier路线同时把 Cursor 的保存动作设置为只触发 Prettier 格式化不让 ESLint 在保存时自动修复。ESLint 留在你手动运行npm run lint或者在 CI 里做检查。这样每种工具各司其职不会再因为两个格式化器的竞争导致“保存一会变单引号一会变双引号”这种哭笑不得的问题。顺带提一句现在很多模板比如 Vite 初始化 Vue 项目时选上的 ESLint Prettier已经自动配好了eslint-config-prettier。如果你是新项目选模板时直接勾选即可如果是老项目检查一下 eslint.config.js 里是否继承了 prettier 相关配置。搜索结果热词里也有“vue router pinia eslint prettier vitest单元测试 这个是选什么”这类问题其实就是让你选择前端工程化配套。大多数情况下选默认推荐组合就行但格式化部分必须保证 Prettier 有最终话语权。5.2 Volar/TypeScript 与 .vue 文件的格式化问题如果你在做 Vue 3 项目还开着VolarVue Language Features或Vue Official扩展那么你会碰到一个非常典型的“部分生效”问题script标签里的 TypeScript 代码保存后正常格式化但template里的 HTML 结构没有任何变化或者反过来。原因是 .vue 文件是一个多语言混合文件格式化器需要安装对应的语言服务才能正确处理。解决办法是在设置里对[vue]语言显式指定默认格式化器为 Prettier我前面给过配置。同时确保 Volar 扩展的 “Vue: Takeover Mode” 或者相关格式化能力不会覆盖 Prettier。如果你发现 template 部分仍然不格式化可以直接在命令面板里执行 “Format Document With...” → 选择 Prettier。如果此时 Prettier 不出现说明 .vue 文件没有被 Prettier 扩展识别为可格式化文件你需要检查 Prettier 扩展是否有针对 Vue 的插件支持。React 项目同样有这个隐患.tsx、.jsx文件的情况稍好但如果你安装了某些额外的 HTML/CSS 格式化扩展比如 Beautify它们可能标记自己支持 JavaScript/TypeScript然后在优先级上把 Prettier 挤下去了。我的原则是整个项目里只保留 Prettier 一个格式化器凡是名字里带 “Formatter” 且不认识的扩展一律禁用这样能减少 80% 的同类问题。5.3 团队项目里别忽视共享配置与个人配置的覆盖关系团队协作项目中.vscode/settings.json通常会被提交进仓库里作为统一的编辑器规范。如果你发现 Prettier 不生效而此时仓库里存在.vscode/settings.json并且内部写了一些奇怪的设置比如editor.formatOnSave: false、editor.defaultFormatter: vscode.html-language-features那这个文件就是罪魁祸首。它会被所有团队成员共享覆盖本地配置因此你在 Cursor 设置里怎么改全局设置都没用因为在项目级设置优先的规则下仓库里的配置才是最终生效的。处理方式有两种如果这个项目是你自己维护的直接把 .vscode/settings.json 改正确并提交如果项目里那份配置已经过时或者存在恶意/错误的配置建议先在本地覆盖测试然后与团队成员沟通修正。类似地有些项目还会在.vscode/extensions.json里推荐扩展但推荐不代表自动禁用所以可以忽略它专心检查 settings.json 即可。还有一个小点多个配置文件共存时用户级、工作组级、项目级的优先级你要记牢——项目级 工作组级 用户级。在排查时永远先打开项目根目录的 .vscode/settings.json用排除法确认它没有“捣乱”。6. 排查命令、速查表与我的推荐配置6.1 几条真正有用的调试命令和操作除了前面零零散散提到的命令我再集中整理一份排查 Prettier 问题时最高频使用的操作清单按顺序执行基本能覆盖所有已知问题命令面板 → Format Document格式化文档手动触发一次格式化判断格式化器链路是否正常。命令面板 → Format Document With...格式化文档为…手动选择 Prettier并设置默认格式化器。命令面板 → 输入 “Prettier: Show Output” / 打开输出面板选择 “Prettier”查看 Prettier 扩展运行日志确认是否报错、是否找到配置、是否忽略了文件。终端执行npx prettier --check src/**/*.ts绕过编辑器直接验证 Prettier 本身和配置文件是否工作正常。终端执行npx prettier --write src/某文件.ts如果终端能正确格式化说明问题只和编辑器扩展/触发设置相关如果终端也报错那就是依赖安装、配置文件或 Prettier 版本的问题。npx prettier --find-config-path src/某文件.ts判断当前文件实际命中了哪个配置文件特别适合 monorepo 和多配置项目。6.2 Cursor 的全局和项目设置里我建议检查的 10 项下面这张表是我处理 Cursor Prettier 问题时最终沉淀下来的检查清单。每一项我都标出了推荐值你可以直接对照自己的设置排查设置项查找/写入位置推荐值说明editor.formatOnSave设置 → 文本编辑器 → 格式化勾选保存时自动格式化的总开关editor.defaultFormatter设置 → 文本编辑器 → 格式化esbenp.prettier-vscode全局默认格式化器[typescript]/[javascript]/[vue]的 formatter设置 → 语言特定设置esbenp.prettier-vscode防止语言级覆盖prettier.requireConfig设置 → 扩展 → Prettier建议false新项目建议 true是否要求必须有配置文件才格式化设 true 后无配置则静默跳过prettier.prettierPath设置 → 扩展 → Prettier本地依赖路径如node_modules/prettier确保和命令行使用同一版本 Prettierprettier.configPath设置 → 扩展 → Prettier留空自动查找或指定绝对路径显式指定配置文件位置适合 monorepoESLint 保存时格式化设置 → 扩展 → ESLint建议关闭eslint.codeActionsOnSave避免 ESLint 和 Prettier 抢格式化权.vscode/settings.json项目根目录内容与上述推荐值一致项目级优先级最高先检查.prettierignore项目根目录确认没有误伤 src 目录被忽略的文件不格式化.editorconfig项目根目录与 .prettierrc 的缩进/行尾符一致确保不会覆盖 Prettier 配置6.3 一劳永逸的推荐配置最后我把目前我所有项目都在用的的一套配置完整放出来你可以直接抄走根据项目情况删减。项目根目录.vscode/settings.json{ editor.formatOnSave: true, editor.defaultFormatter: esbenp.prettier-vscode, editor.codeActionsOnSave: { source.fixAll.eslint: explicit }, [javascript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [typescript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [javascriptreact]: { editor.defaultFormatter: esbenp.prettier-vscode }, [typescriptreact]: { editor.defaultFormatter: esbenp.prettier-vscode }, [vue]: { editor.defaultFormatter: esbenp.prettier-vscode }, [json]: { editor.defaultFormatter: esbenp.prettier-vscode }, prettier.requireConfig: false, prettier.prettierPath: ./node_modules/prettier }项目根目录.prettierrc基础示例{ semi: false, singleQuote: true, printWidth: 100, tabWidth: 2, trailingComma: es5, arrowParens: always, endOfLine: lf }项目根目录.editorconfig注意保持风格一致root true [*] charset utf-8 indent_style space indent_size 2 end_of_line lf insert_final_newline true trim_trailing_whitespace true这套配置的好处是保存时只让 Prettier 负责格式化ESLint 只在必要时通过 codeActionsOnSave 修复可自动修复的问题而且两者依赖的缩进、引号、分号规则完全一致不会再出现互相打架的结果。如果你用的是 Vue 项目建议把prettier.requireConfig始终保持为true并且确保根目录有 .prettierrc 文件这样团队里每个人拿到代码后看到的格式都是一样的不会出现“我本地格式化完 commit你 pull 下来再格式化又变一遍”的噩梦。我的个人经验是所有这类“不生效”问题绝大多数都不是 Cursor 的 bug而是设置优先级和工具职责边界不清导致的。Cursor 作为 AI 编辑器它自己的能力很强但它同时也继承了 VSCode 那套完善的配置体系你得主动告诉它“格式化的事情不要自己管交给 Prettier”。只要把这条规则在全局和项目层面都写明之后再安装 AI 扩展、切换项目环境基本就不会再遇到格式化失效的问题了。
