缩进参考线是逻辑锚点而非装饰，通过editor.guides.indentation等设置可视化缩进层级，辅助识别代码块归属；垂直参考线（rulers）则按列固定显示，用于长度提示，二者功能不同、互不干扰。
缩进参考线（indent guides）不是装饰，是逻辑锚点
VSCode 的 editor.guides.indentation 和 editor.renderIndentGuides 控制的垂直线，本质是把缩进层级“可视化”——Python 里少一个空格报 IndentationError，JS 里 if 块嵌套深了容易看串，这些线就是你肉眼识别块归属的依据。它不改变代码，但能立刻暴露“这行其实该属于上一个 for 循环”这类结构性误判。
常见错误现象：开了 editor.renderIndentGuides 却看不到线 —— 大概率是当前颜色主题把导轨色设成了透明（比如某些高对比度主题），或被工作区设置覆盖。临时切到 Default Dark+ 主题验证即可。
关键参数差异：
-
editor.renderIndentGuides：老式总开关，设为true就启用基础线 -
editor.guides.indentation：新版本（1.60+）推荐项，更细粒度控制，且默认true，但部分插件会重置它 -
editor.guides.bracketPairs：配合括号配色插件（如Bracket Pair Colorizer 2）用，让{和}所在列也出现引导线，强化作用域边界感
垂直参考线（rulers）和缩进线别混用
editor.rulers 是另一套东西：它按列数画固定竖线（如 "editor.rulers": [80, 120]），常用于提示单行长度上限，和代码块逻辑无关。很多人搜“对齐线”却配 rulers，结果发现线不会随缩进动——因为它是静态列标尺，不是动态缩进锚点。
容易踩的坑：
- 在
settings.json里同时写了editor.rulers和editor.guides.indentation，误以为两者叠加增强效果，实际互不干扰 - 给
editor.rulers填负数或字符串（如["80"]），导致整个配置失效，VSCode 不报错但静默忽略 - 在 JavaScript 工作区设置了
"editor.rulers": [100]，但打开的是.py文件——语言专属设置只对匹配类型生效
颜色与样式自定义要分层处理
单纯开启缩进线还不够，不同层级用不同颜色才能一眼区分“这是函数体”还是“这是循环内层”。VSCode 原生不支持多级色，得靠插件补足：
-
indent-rainbow：最常用，自动给 2/4/6/8 空格缩进分配彩虹色，禁用方法是在设置里关掉indentRainbow.colorOnRuler - 如果已装
Bracket Pair Colorizer 2，再开editor.guides.bracketPairs，括号对所在列会出现加粗线，和彩虹缩进线形成双重提示 - 改颜色要直接写 CSS 变量：在
settings.json加"workbench.colorCustomizations"，例如"editorIndentGuide.background1": "#37474f"，注意数字 1–6 对应不同层级
性能影响：indent-rainbow 在超长文件（>5000 行）中可能轻微卡顿，可设 "indentRainbow.skipLines": 100 跳过前 100 行渲染。
格式化工具才是对齐动作的执行者
缩进参考线只负责“让你看见对齐”，真正“让代码对齐”的是格式化器（如 Prettier 或 Black）。没有它们，手动调空格对齐效率极低，且易出错。
必须配对的关键设置：
-
editor.formatOnSave：设为true，否则保存不触发对齐 -
editor.defaultFormatter：必须指定具体扩展 ID，比如 JavaScript 项目填esbenp.prettier-vscode，Python 项目填ms-python.black-formatter -
editor.detectIndentation：保持默认true，但注意它只在文件打开时读一次缩进风格，已有混杂缩进的文件需先手动统一（选中 →Ctrl+Shift+P→ “Convert Indentation to Spaces”）
复杂点在于：Prettier 的对齐行为依赖原始换行结构。比如 const obj = { a: 1, b: 2 }; 不会拆成多行对齐，除非你先手动断行或设 "printWidth": 60 压窄阈值。这点容易被忽略——线画得再清楚，格式化器没被正确调用，代码照样挤在一起。
