必须先确认光标在物理行首，因sublime的home键默认停在缩进后首字符前，非真正行首；若未对齐即输"，会导致引号前多空格或位置错乱，破坏格式与语法。
多光标加引号前，为什么必须先确认光标真正在行首？
Sublime 的 Home 键默认停在“缩进后第一个非空字符前”，不是文件物理行首。比如有 4 空格缩进的 user_id，按一次 Home 光标停在 u 前；再按一次或用 Ctrl+Home（Win）/Cmd+Home（macOS）才能到最左端。否则输 " 会变成 "user_id 而不是 "user_id（引号紧贴内容），更糟的是缩进不一致时，有的行变成 " user_id（引号后带空格）。
- 必须先选中目标行（鼠标拖选 /
Ctrl+L 连续选 / Ctrl+Shift+↓ 扩展）
- 再按
Ctrl+Shift+L（Win/Linux）或 Cmd+Shift+L（macOS）激活多光标
- 每行光标出现后，立刻按
←（左箭头）或 Ctrl+Home/Cmd+Home，确保光标统一落在第 0 列
- 此时输入
"，才能保证所有引号都紧贴内容开头
多光标加右引号和逗号时，行尾空格会导致什么问题？
如果某行末尾有空格或 Tab，按 End 或 Cmd+→ 后光标会停在空白处，再输 ", 就变成 item ",，而非 "item",。这种错位肉眼难察觉，但 JSON 或数组语法直接报错。
- 加左引号前，先执行
Ctrl+Shift+P → 输入 Trim Trailing White Space 清理尾部空白
- 加右引号时，优先用
End（Win）/Cmd+→（macOS），比连按 → 更稳
- 若需同时加
",，建议分两步：先加 "，再统一用正则替换 $ → ",，避免手动定位误差
正则替换 ^ 和 $ 为什么比多光标更适合加逗号？
多光标无法自动识别“最后一行不加逗号”这个逻辑，而正则能精准控制边界。例如处理 CSV 字段或 JS 数组元素时，^ 匹配每行开头，$ 匹配每行结尾，组合使用可避免末尾多余逗号。
- 给每行加
"xxx",：查找 ^(.+)$，替换为 "$1",
- 排除最后一行：先用
Ctrl+Shift+P → Select All，再 Ctrl+Shift+L，删掉最后一个光标（按 ↑ 选中最后一行，Esc 取消该光标），再统一加 ", —— 但这手动操作易漏，不如正则可靠
- 注意：
^ 和 $ 必须在勾选 .*（正则模式）后才生效；不勾选就当字面量处理，替换无效
列选择（Alt+拖拽）加引号为什么一定失败？Alt+拖拽 是像素级列选择，不是按行逻辑对齐。只要某行比其他行短一个字符，拖出来的列就会偏移——比如 user_id 和 age 并排，列选可能切开 user_id 成 "user_ 和 id"，或者把引号插进缩进中间。
- 视觉上对齐 ≠ 字节位置一致：Tab 和空格混用、不同缩进层级都会导致错位
- 即使全用空格，行长不等也会让列选区域在不同行落在不同逻辑位置
- 唯一补救方式是提前统一缩进（
Ctrl+Shift+P → Indentation: Convert to Spaces），但不如直接放弃列选，改用多光标或正则
Ctrl+L 连续选 / Ctrl+Shift+↓ 扩展）Ctrl+Shift+L（Win/Linux）或 Cmd+Shift+L（macOS）激活多光标←（左箭头）或 Ctrl+Home/Cmd+Home，确保光标统一落在第 0 列"，才能保证所有引号都紧贴内容开头End 或 Cmd+→ 后光标会停在空白处，再输 ", 就变成 item ",，而非 "item",。这种错位肉眼难察觉，但 JSON 或数组语法直接报错。
- 加左引号前，先执行
Ctrl+Shift+P→ 输入Trim Trailing White Space清理尾部空白 - 加右引号时，优先用
End（Win）/Cmd+→（macOS），比连按→更稳 - 若需同时加
",，建议分两步：先加"，再统一用正则替换$→",，避免手动定位误差
正则替换 ^ 和 $ 为什么比多光标更适合加逗号？
多光标无法自动识别“最后一行不加逗号”这个逻辑，而正则能精准控制边界。例如处理 CSV 字段或 JS 数组元素时，^ 匹配每行开头，$ 匹配每行结尾，组合使用可避免末尾多余逗号。
- 给每行加
"xxx",：查找 ^(.+)$，替换为 "$1",
- 排除最后一行：先用
Ctrl+Shift+P → Select All，再 Ctrl+Shift+L，删掉最后一个光标（按 ↑ 选中最后一行，Esc 取消该光标），再统一加 ", —— 但这手动操作易漏，不如正则可靠
- 注意：
^ 和 $ 必须在勾选 .*（正则模式）后才生效；不勾选就当字面量处理，替换无效
列选择（Alt+拖拽）加引号为什么一定失败？Alt+拖拽 是像素级列选择，不是按行逻辑对齐。只要某行比其他行短一个字符，拖出来的列就会偏移——比如 user_id 和 age 并排，列选可能切开 user_id 成 "user_ 和 id"，或者把引号插进缩进中间。
- 视觉上对齐 ≠ 字节位置一致：Tab 和空格混用、不同缩进层级都会导致错位
- 即使全用空格，行长不等也会让列选区域在不同行落在不同逻辑位置
- 唯一补救方式是提前统一缩进（
Ctrl+Shift+P → Indentation: Convert to Spaces），但不如直接放弃列选，改用多光标或正则
"xxx",：查找 ^(.+)$，替换为 "$1",
Ctrl+Shift+P → Select All，再 Ctrl+Shift+L，删掉最后一个光标（按 ↑ 选中最后一行，Esc 取消该光标），再统一加 ", —— 但这手动操作易漏，不如正则可靠^ 和 $ 必须在勾选 .*（正则模式）后才生效；不勾选就当字面量处理，替换无效Alt+拖拽）加引号为什么一定失败？Alt+拖拽 是像素级列选择，不是按行逻辑对齐。只要某行比其他行短一个字符，拖出来的列就会偏移——比如 user_id 和 age 并排，列选可能切开 user_id 成 "user_ 和 id"，或者把引号插进缩进中间。
- 视觉上对齐 ≠ 字节位置一致：Tab 和空格混用、不同缩进层级都会导致错位
- 即使全用空格，行长不等也会让列选区域在不同行落在不同逻辑位置
- 唯一补救方式是提前统一缩进（
Ctrl+Shift+P→Indentation: Convert to Spaces），但不如直接放弃列选，改用多光标或正则
真正容易被忽略的是：多光标加完左引号后，没人检查是否所有光标都还在行首——一旦某行因缩进逻辑特殊（比如含 Tab 或混合缩进），Home 就失效，那个光标会卡在中间，输进去的引号就嵌在代码里了。
