缩进对不齐不是文件损坏，而是vs code因editor.detectindentation误判开头格式导致的连锁偏移；应关闭该选项，并统一editor.insertspaces、tabsize及prettier/eslint的tabwidth，同时开启renderwhitespace可视化排查混用。
缩进对不齐不是文件坏了，是 VS Code 在“猜”你想要什么缩进时猜错了——它只看开头几行（甚至一个空行、一段注释）就决定整份文件该用 Tab 还是空格、该用几个字符宽。真正起效的不是调 tabSize，而是关掉 editor.detectIndentation 并让编辑器设置、语言模式、格式化插件三者对齐。
为什么刚打开文件缩进就错位？关掉 editor.detectIndentation
VS Code 默认开启 editor.detectIndentation，它读取文件前几行就判定全文件该用 Tab 还是空格、该用几个字符宽。一旦开头混了格式（比如第一行是 2 空格，第二行是 Tab + 4 空格），后续所有自动缩进、光标跳转、Shift+Alt+F 格式化都会偏移。
- 这不是 bug，是设计行为：它优先“迁就”已有内容，而非执行你设定的规范
- 解决方法不是调低
tabSize，而是在项目根目录建.vscode/settings.json，写入：{"editor.detectIndentation": false,"editor.insertSpaces": true,"editor.tabSize": 2} - 切勿只改用户级
settings.json（全局路径），否则新项目仍会复现
粘贴后缩进崩了？禁用 editor.formatOnPaste 并检查 snippet 基准
VS Code 的 snippet 和粘贴逻辑默认按“光标所在行首空白”对齐，不是按语义层级。从 2 空格缩进的函数里粘贴一个为 4 空格写的 log 片段， 占位符就会被硬塞进错误列。
- 临时解法：粘贴前按
Ctrl+Shift+P→ 输入Toggle Render Whitespace，确认目标位置没有隐藏Tab（→）干扰 - 长期解法：在工作区设置中加
"editor.formatOnPaste": false，避免格式化插件在粘贴瞬间重写缩进 - 自定义 snippet 时，在
body第一行手动加两个空格（或匹配项目tabSize的空格数），比依赖自动推导更可靠
Prettier/ESLint 格式化后反而更乱？核对 tabWidth 是否与编辑器对齐
VS Code 编辑器设置只是基础，真正动手重排的是 Prettier 或 ESLint。如果 prettier.tabWidth 是 2，但 VS Code 的 editor.tabSize 是 4，保存时就会出现“缩进显示为 4 列，但格式化器认为该用 2 列”的撕裂感。
- 查 Prettier：检查
.prettierrc中的tabWidth字段 - 查 ESLint：若用了
eslint-config-prettier，确认其tabWidth参数一致 - 验证方式：关掉所有格式化插件，只用 VS Code 原生
Shift+Alt+F，如果此时正常，问题 100% 出在插件配置冲突
怎么让空格和制表符“显形”？开 editor.renderWhitespace
editor.renderWhitespace 设为 "all" 后，空格显示为 ·，Tab 显示为 →，一眼就能看出混用位置。这是排查缩进错乱最直接的手段。
- 该设置必须显式开启，某些主题或远程开发环境可能默认禁用
- 配合
editor.renderIndentGuides（缩进参考线）一起开，能同时看到“缩进层级”和“实际字符”，快速定位混用点 - 已错乱的文件，先手动执行
Convert Indentation to Spaces统一字符，再关editor.detectIndentation
复杂点在于：缩进对齐不是单点开关能解决的事，它横跨语言识别、编辑器配置、格式化插件、甚至 Git 提交前的换行符处理。最容易被忽略的是右下角语言模式是否正确——Vue 文件误判为 HTML，Python 文件被当成 Plain Text，所有缩进设置都会失效。
