Prettier/ESLint缩进“打架”主因是tabWidth等配置冲突及defaultFormatter未正确绑定；需统一.prettierrc、ESLint规则与VSCode的editor.tabSize/insertSpaces，并在.vscode/settings.json中为对应语言显式指定defaultFormatter。
为什么Prettier/ESLint一启用，缩进就“打架”？
不是插件坏了，是它和VSCode编辑器设置在抢缩进控制权。Prettier的tabWidth和useTabs字段会直接覆盖editor.tabSize与editor.insertSpaces——哪怕你在设置里写死了2空格，只要.prettierrc里是"tabWidth": 4，保存时就会全变成4格。
- 检查
.prettierrc、package.json里的prettier字段，或prettier.config.js，确认tabWidth数值和项目要求一致 - 搜
useTabs：如果设为true，必须同步把editor.insertSpaces关掉，否则VSCode按空格输、Prettier又强行转Tab，光标跳转都会错位 - ESLint用户重点看
@typescript-eslint/indent规则——它的tabWidth参数不继承Prettier，得单独配，否则eslint --fix会按自己的规则重排
右下角显示Spaces: 2，但格式化后缩进还是4格？查defaultFormatter链路
VSCode只负责派发“格式化”指令，真正动手的是当前语言绑定的defaultFormatter。如果[javascript]块里没指定格式化器，或者指错了ID，VSCode就会 fallback 到内置逻辑（比如用vscode.typescript-language-features），而它默认用4空格，且不读Prettier配置。
- 按
Ctrl+Shift+P→ 输入Format Document With，看列表里哪个被标✓；如果不是esbenp.prettier-vscode，说明语言绑定失效 - 在
.vscode/settings.json中显式声明："[javascript]": {"editor.defaultFormatter": "esbenp.pretterr-vscode"}（注意拼写） - Python项目同理：确保
[python]块绑的是ms-python.black-formatter或ms-python.autopep8，而非留空
Convert Indentation命令灰色不可点？语言模式和detectIndentation在作祟
这个命令只在“当前文件被识别为有效语言模式 + 编辑器没自动锁定缩进风格”时才可用。一旦editor.detectIndentation开着，VSCode会认为“这文件已有固定风格”，拒绝让你手动转换。
- 先点右下角语言标识，确认显示的是
JavaScript、Python等，不是Plain Text——后者会让所有缩进命令失效 - 临时关闭
editor.detectIndentation（在设置里搜，设为false），命令立刻变亮 - 执行
Convert Indentation to Spaces后，再开回detectIndentation也没关系，因为转换已落地；但长期建议保持关闭，避免下次打开旧文件又被误判
粘贴后缩进突变，别怪formatOnPaste，先看它有没有“真生效”
editor.formatOnPaste本身不决定缩进宽度，它只是在粘贴瞬间触发一次Format Selection。如果此时格式化器没就位、或语言模式错误、或tabWidth不匹配，结果就是随机缩进——比如从网页粘JS，Prettier按4格重排，而你项目用2格。
- 验证是否真生效：粘贴前按
Ctrl+Shift+P→ 输入Toggle Render Whitespace，观察光标所在行首是·（空格）还是→（Tab）；混用时粘贴必然崩 - 关掉
editor.formatOnPaste是最稳方案，尤其协作项目；需要时手动Shift+Alt+F更可控 - 若坚持开启，必须确保：语言模式正确 +
defaultFormatter已绑定 +prettier.tabWidth和editor.tabSize完全一致
最易忽略的一点：插件冲突往往藏在“多层配置叠加”里——用户级settings.json、工作区.vscode/settings.json、语言专属块、.prettierrc、ESLint规则，五层可能各写一个tabWidth，最终生效的永远是优先级最高那层，而不是你最后改的那一处。
