ctrl+shift+l 是按换行符切片选区并放置光标，非开启多行编辑；home 键不跳物理行首，需用全选+左箭头或命令精确定位；列选择需禁用 drag_text 并用等宽字体；ctrl+d 为字面匹配，须结合 whole word 或正则 \b 限定词边界。
Ctrl+Shift+L 拆光标前必须选中带换行符的区域
这个快捷键不是“开启多行编辑”，而是把当前选区按 \n 切片——每遇到一个换行符，就在其前位置放一个光标。没反应或只出一个光标，基本是因为选区没跨行，或者鼠标拖选时漏掉了最后一行末尾的换行符。
安全做法是：
- 用
Ctrl+L（Windows/Linux）或Cmd+L（macOS）先选中第一行 - 再按住
Shift+↓向下扩展选区，确保状态栏显示“x lines selected” - 最后按
Ctrl+Shift+L，光标会稳稳落在每行末尾（换行符前）
如果选区里有空行，它也会拆出光标，但光标停在行首；处理配置文件时得手动检查是否遗漏。
行首插入前缀必须避开 Home 的“逻辑首”陷阱
Home 键默认跳到第一个非空字符，不是物理行首。缩进代码里按 Home，光标会停在 后面，导致你输的 console.log( 插在缩进中间，破坏格式。
真正可靠的两种方式：
- 选中目标行 →
Ctrl+Shift+L→ 按Ctrl+Shift+P输入Move to Beginning of Line（内置命令，无需插件） - 或更直接：按
Ctrl+A全选当前行 → 按一次←（左箭头），光标就贴在行最开头
别依赖视觉对齐——Sublime 定位靠字符数，不是像素。中英文混排或字体非等宽时，Home 行为更不可靠。
列选择（Alt+拖动）失效往往因为 drag_text 或字体问题
列选择不是快捷键失灵，而是触发条件没满足：Alt+Shift+鼠标拖动（Windows/Linux）或 Option+Shift+鼠标拖动（macOS）才是正确组合。单独按 Alt 无效，且和多光标模式互斥。
常见卡点：
-
"drag_text": true在设置里开着——这会让鼠标一碰就拖动文本，而不是列选；必须设为false - 字体不是等宽（如系统默认雅黑），中文字符占位宽度 ≠ ASCII，视觉上光标偏移；换成
Consolas或Fira Code立刻稳定 - 某行太短，光标停在该行尾——这是正常行为，不是 bug；若需强制对齐，先补空格或用
AlignTab插件
Ctrl+D 匹配变量名时容易误伤 user_id_list 这类词
Ctrl+D 是严格字面匹配，不区分单词边界。双击选中 user_id 后连按 Ctrl+D，user_id_list 和 USER_ID 都会被框中——前者多了后缀，后者大小写不符，但 Sublime 只看字符串是否连续出现。
控制匹配精度的关键动作：
- 确认要改的是完整单词？先打开替换面板（
Ctrl+H），勾选Whole Word，再用Ctrl+D增量选中 - 想跳过注释里的同名字符串？按
Ctrl+K再按Ctrl+D，跳过当前高亮项，继续往后找 - 需要正则限定？先按
Alt+R开启正则，再搜\buser_id\b，然后按Ctrl+Alt+G（Win/Linux）或Cmd+Ctrl+G（macOS）全量匹配
最危险的不是不会加光标，而是忘了 Ctrl+D 和 Ctrl+Alt+G 都不识别语义——它们照单全收所有字面匹配，包括字符串字面量、注释、正则模式本身。
