vscode 的 alt 键仅支持列选择而非语法对齐；真正实现代码结构对齐的是 prettier 格式化器，需满足语言模式正确、插件启用并配置 .prettierrc 等条件。
VSCode 里 Alt 键本身不负责“对齐”，只管“列选择”
按住 Alt（Windows/Linux）或 Option（macOS）拖拽鼠标，VSCode 进入的是**列选择模式**，它选中的是一个矩形区域，所有光标严格落在相同字符列号上。这不是语法感知的“对齐”，也不会自动把 = 或 : 排成一列——它只是按坐标画框。
常见误解：以为拖宽一点就能“多列对齐”。实际只要起始列和结束列固定，它就只在那一竖条里操作；如果某行用 TAB、另一行用 4 个空格，视觉对齐但列号不同，光标就会错位甚至跳过该行。
- 想批量在每行相同位置插入内容（比如统一加
const前缀），Alt+拖拽是最稳的 - 想让对象属性的
:垂直对齐？这得靠格式化器（如 Prettier），不是Alt的事 -
Ctrl+V粘贴时，只有第一个光标位置会填入剪贴板内容——其余光标不会同步，这是设计限制，不是 bug
真正能“对齐多行结构”的是 Prettier，不是 Alt
所谓“代码对齐”，比如让对象字面量的 key 和 value 分开两列、函数参数换行后垂直排布，全是 Prettier 在干活。VSCode 只是转发 Shift+Alt+F 请求，自己不带任何对齐逻辑。
必须满足三个条件，Prettier 才会触发对齐：
- 当前文件语言模式正确（右下角显示
JavaScript，不是Plain Text） - 已安装并启用
esbenp.prettier-vscode，且设为默认格式化器：editor.defaultFormatter=esbenp.prettier-vscode - 项目有
.prettierrc且含"trailingComma": "es5"—— 没尾逗号，Prettier 认为“没必要多行”，直接压成一行
printWidth 也关键：设为 80 比较稳妥；设成 120，本该换行对齐的代码可能被硬塞进单行，看起来就像“没对齐”。
Alt+Shift+拖拽 vs Ctrl+Alt+↓：哪种更适合结构化对齐？
两者都生成多光标，但行为差异很大：
-
Alt+Shift+拖拽：选中矩形区域，光标列号绝对一致，适合 CSV、日志、JSON key 名这类字段位置固定的文本 -
Ctrl+Alt+↓：在“当前光标列”向下追加光标，但一旦某行该列是空格或已超出行末，新光标会自动贴到行尾，导致错位 - 安全做法：先按
Home把所有光标拉回行首，再Ctrl+Alt+↓；或提前用Alt+Shift+拖拽框出干净列区
超过 100 行连续追加时，VSCode 默认截断（editor.multiCursorLimit = 100），调高后卡顿明显，不如分批操作。
为什么 Shift+Alt+F 没反应？别怪 Alt 键
快捷键没失效，是 VSCode 没找到可用的格式化器。它只负责发请求，不自带实现。
- 检查右下角语言标识是否正确（如
JavaScript） - 确认已安装
Prettier插件，并在设置中指定为默认格式化器（不是“Default Formatter”那个模糊选项） - 项目根目录若有
.prettierrc或.editorconfig，它们会覆盖全局设置，需核对tabWidth和useTabs是否与编辑器缩进设置一致
复杂点在于：Prettier 的对齐是“条件式”的——它只在代码已为多行时重排，不会强行拆开单行表达式。想对齐 let a = 1; let b = 2; 这种并列语句？Prettier 默认压成一行，你得手动换行加逗号，再格式化。
