prettier 配置不生效主因是本地设置覆盖项目配置或扩展未对齐；须在项目根目录放 .prettierrc，启用 editor.formatonsave 并设 editor.defaultformatter 为 prettier，且开启 prettier.requireconfig。
为什么团队里 Prettier 配置总不生效？
VSCode 本身不自带代码格式化能力，它依赖扩展（如 Prettier、ESLint）和配置文件协同工作。团队格式化不统一，90% 是因为本地设置覆盖了项目级配置，或扩展行为未对齐。
关键判断：仅靠修改 VSCode 的 settings.json（用户级或工作区级）无法可靠统一——它容易被开发者手动改写、忽略、或因扩展版本差异导致行为不一致。
- 必须在项目根目录放
.prettierrc（或prettier.config.js）定义规则，这是 Prettier 唯一认的“权威配置” - 必须启用
"editor.formatOnSave": true，但该设置应写在.vscode/settings.json中（而非用户全局设置），并加// @ts-ignore注释提示“此为团队强制配置” - 禁用其他格式化工具干扰：在
.vscode/settings.json中显式指定"editor.defaultFormatter"，例如 React 项目设为"esbenp.prettier-vscode"
如何让 ESLint 和 Prettier 不打架？
ESLint 检查逻辑，Prettier 处理样式——两者职责不同，但默认冲突。常见现象是保存后代码被反复格式化、缩进错乱、分号消失又出现。
根本解法不是“关掉一个”，而是让 ESLint 把格式化规则交给 Prettier 管理：
- 安装
eslint-config-prettier并在.eslintrc.js的extends末尾加入它，用于关闭所有和 Prettier 冲突的 ESLint 格式规则 - 安装
eslint-plugin-prettier并在plugins和rules中启用，把 Prettier 当作 ESLint 的一条规则来运行（即“Prettier 错误=ESLint 错误”） - 确保
.vscode/settings.json中"eslint.format.enable": true，且"editor.formatOnSave"对应的 formatter 是 Prettier，而非 ESLint 扩展自身
.vscode/settings.json 里哪些配置不能删？
这个文件是团队格式化落地的“最后一道保险”，但它极易被 Git 忽略或开发者手动清空。以下三项是硬性保留项，缺一不可：
-
"editor.formatOnSave": true—— 启用自动格式化的开关，不设则所有配置形同虚设 -
"editor.defaultFormatter": "esbenp.prettier-vscode"—— 明确指定谁来格式化，避免多人安装不同 formatter 导致行为差异 -
"prettier.requireConfig": true—— 强制 Prettier 只在找到.prettierrc时才工作，防止它用内置默认值污染团队风格
注意：.vscode/ 目录需提交到 Git（除非有特殊安全要求），否则新成员克隆后根本不会加载这些设置。
为什么 Mac 和 Windows 下格式化结果偶尔不一致？
表面看是换行符（CRLF vs LF）问题，实际根因常是 prettier 版本或 Node.js 运行时差异。Prettier 5.0+ 默认使用 endOfLine: "lf"，但若本地 Node 版本过低（如
- 统一用
npm install --save-dev prettier@latest安装，并在package.json的scripts中定义"format": "prettier --write ."，所有成员都走 npm script 调用 - 在
.prettierrc中显式声明"endOfLine": "lf"，不依赖默认值 - 检查
git config core.autocrlf：Windows 建议设为true，Mac/Linux 设为input，避免 Git 自动转换干扰编辑器行为
最易被忽略的是：团队里有人用 VSCode Remote-SSH 或 WSL，却没在远程环境里重装 Prettier 扩展——此时格式化实际发生在远端，本地配置完全无效。
