prettier-vscode格式化慢主因是执行环境低效而非插件本身卡顿：文件监听未排除node_modules/dist、多格式化扩展冲突、monorepo根目录误触发全量解析；应配置files.watcherexclude、禁用eslint等冲突扩展、启用prettier缓存并限制作用域。
prettier-vscode 格式化慢，不是插件本身“卡”，而是它被拖进了一个低效的执行环境里。关掉几个配置、删掉几行监听、禁用一个扩展，速度常能提升 2–5 倍。
为什么 prettier-vscode 会变慢？
格式化触发后，VSCode 实际要干三件事：扫描文件变更 → 解析 AST → 调用 Prettier 核心重写代码。前两步最容易被拖累：
- 文件监视器（files.watcherExclude 没配）持续监听 node_modules 或 dist，导致事件队列堆积，主线程卡住
- 多个格式化类扩展（如 ESLint、Beautify）同时注册 onSave 钩子，互相竞争资源
- 工作区打开的是整个 monorepo 根目录，而不是具体子包，prettier-vscode 会尝试为所有语言文件加载解析器
files.watcherExclude 必须配，且优先级高于 search.exclude
这是最常被忽略、效果最立竿见影的一环。VSCode 底层用的是操作系统原生文件监听机制（inotify / fsevents），一旦监听路径里包含百万级文件的目录，编辑器就容易假死。
在 .vscode/settings.json 中加入：
{
"files.watcherExclude": {
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.git/**": true,
"**/logs/**": true,
"**/coverage/**": true
}
}
-
files.watcherExclude是内核级过滤，生效在 VSCode 主线程之前；search.exclude只影响搜索面板，对格式化无感 - Windows 用户若仍卡顿，可加一行：
"files.useExperimentalFileWatcher": false，回退到稳定版监听器 - 别只信文档说的“排除 node_modules”——如果你项目里有
packages/*/dist或apps/*/public，也要手动加上
禁用冲突扩展比调参数更有效
prettier-vscode 和 ESLint 插件默认都监听 onSave，但它们的执行没有顺序保证。你可能看到控制台报错：Failed to format: Error: Cannot find module 'prettier'，其实是 ESLint 先抢跑了，把 Prettier 的模块缓存搞乱了。
建议操作：
- 运行命令
Extensions: Show Running Extensions，看哪些扩展占 CPU >10% —— 特别盯住带 “Auto Format”、“On Type”、“Live Preview” 字样的 - 临时禁用
ESLint，改用"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，让修复动作由 Prettier 触发后统一调度 - 彻底卸载
JavaScript Booster、Auto Rename Tag这类高频 DOM 监听型扩展，它们和格式化共享同一事件循环
启用 Prettier 缓存并限制作用域
Prettier 自带文件内容哈希缓存，但 VSCode 插件默认不开启。没缓存时，每次保存都重新 parse + print，哪怕文件一字未改。在项目根目录加 .prettierrc，确保含以下字段：
{
"cache": true,
"cacheLocation": ".prettiercache"
}
- 缓存文件
.prettiercache会记录每个文件的最后修改时间与 AST 哈希，跳过未变更文件的格式化 - 配合
"prettier.requireConfig": true设置，避免插件在无配置时 fallback 到全局默认规则（那会强制加载全部解析器） - 如果只对
src下的 TS/JS 文件格式化，直接在.prettierignore里写**/*.test.ts和**/types/**，比靠 VSCode 语言检测更可靠
prettier-vscode 的性能瓶颈从来不在“格式化逻辑”，而在它被塞进了太多不该监听的路径、不该协作的扩展、不该参与的文件。真正的优化，是做减法，不是堆配置。
