ctrl+shift+l失效主因是选区非完整行或跨行连续区域；alt+f3全局匹配易误选，ctrl+d逐次匹配更精准；去重首选不排序保序方案；列编辑中方向键作用需区分上下扩展与水平定位。
Ctrl+Shift+L 多行末尾光标失效的常见原因
这个快捷键在选中多行后按下去没反应，或者只在第一行加了光标，大概率不是软件坏了，而是选区没对。Sublime 的 Ctrl+Shift+L（macOS 是 Cmd+Shift+L）只对「已选中的行」生效，且要求选区必须是**完整行或跨行连续区域**。如果只是用鼠标拖出一个不规则矩形框、或者末尾有空格/制表符干扰，它就无法识别为“多行”。
实操建议：
- 先用
Ctrl+L选中当前行，再按住Shift+↓向下扩展行选区，确保状态栏显示 “x lines selected” - 避免用鼠标从中间开始拖选；改用
Ctrl+A全选后立刻按Ctrl+Shift+L，最稳 - 如果文本里混有空行，
Ctrl+Shift+L会在空行也加光标，导致后续输入错位——提前用正则^\s*$删除空行更干净
Alt+F3 和 Ctrl+D 在批量改变量名时的区别
Alt+F3 是全局搜同名词并一次性全选，Ctrl+D 是逐个递进选。两者看着相似，但行为逻辑完全不同：前者依赖词边界和当前光标位置是否触发“全文扫描”，后者只认你当前选中的字符串字面量。
容易踩的坑：
-
Alt+F3会误选带前缀/后缀的词，比如搜user_id，可能连user_id_list一起选了——加正则模式开\buser_id\b更准 -
Ctrl+D连续按太快容易跳过目标，尤其当文档里有注释或字符串含相同词时；建议按一次后停顿半秒，看右下角是否高亮了预期位置再继续 - 改完变量名后，记得手动检查函数调用处是否漏改——
Alt+F3不识别作用域，不会跳过局部变量去改同名全局变量
去重时排序与不排序两种方案的实际取舍
去重分两类需求：一类要保留原始顺序（比如日志时间序列），一类只要唯一值无所谓顺序（比如配置项列表）。Sublime 内置方案默认走排序路线，但实际工作中，**不排序去重更常被忽略却更实用**。
操作要点：
- 排序去重（推荐小文件）：先
Edit → Sort Lines，再替换^(.+)$[\r\n](^\1$[\r\n])+→\1\n；注意 Windows 换行符用\r\n，macOS/Linux 用\n - 不排序去重（大文件/需保序）：装
ShellCommand插件，全选后Ctrl+Alt+|，输awk '!x[$0]++'回车——这行命令原样保留首次出现的行，后续重复行直接丢弃 - 别用正则硬刚“不排序去重”：网上流传的
^(.*)(?:\r\n\1)+$类写法在 Sublime 里基本不可靠，回溯太深容易卡死或漏匹配
列编辑（竖向选择）时方向键失灵怎么办
按 Shift+Right Click 或 Alt+鼠标左键 拉出竖条后，左右方向键没反应？不是快捷键冲突，而是 Sublime 默认把列编辑状态下的方向键绑定为「横向移动光标」，不是「扩展列选区」。
正确做法：
- 列选后，用
↑/↓键上下扩展选区高度，而不是左右；左右方向键只控制光标在当前列内的水平位置 - 想快速拉满整列？鼠标按住
Alt（macOSOption）从首行拖到末行，松手即成；别依赖键盘微调 - 列编辑状态下粘贴内容，会按行数自动对齐——如果源内容行数少于目标列行数，Sublime 会循环粘贴，这点容易引发数据错位，粘贴前务必确认行数一致
Ctrl+Shift+L、哪一刻该切到 Alt+F3、哪一刻必须放弃内置功能去跑 shell 命令。这些边界往往藏在数据特征里：行结构是否规整、重复是否跨上下文、顺序是否敏感——盯住原始文本再动手，比猛敲快捷键靠谱得多。
