ctrl+d是sublime text中按顺序选中下一个相同词的原生命令，从光标位置向下线性查找完全匹配词（默认整词+大小写敏感），首次触发选中当前词，后续逐次跳转；alt+f3则一键全选所有匹配项，无顺序控制。
Ctrl+D 是按顺序选中下一个相同词的唯一原生命令
它不扫描全文，只从当前光标位置开始，向下线性查找**下一个完全匹配的词（默认 whole word + case sensitive）**。第一次按选中光标所在词，第二次按跳到下一个同词位置并加选，第三次继续——节奏必须手动控制，不能连按到底。
常见错误现象：Ctrl+D 按了没反应，大概率是光标停在空格、括号、引号或行首缩进上；想选 user_id 却误中 username，是因为没开 Alt+W（Whole Word 模式）；按太快跳过了注释里的某处，是因为 Ctrl+D 不跳过注释，但某些 syntax 插件会抑制匹配。
- 确保光标落在目标词任意字母内（比如
u或d上），双击单词是最稳的落位方式 - 想跳过当前高亮项（比如第 3 个在字符串里不该改）？先按
Ctrl+K，再按Ctrl+D - 按多了想撤回？用
Ctrl+U，不是Ctrl+Z—— 后者撤销的是编辑内容，前者才撤销上一次选中 - 如果文件有折叠区域，
Ctrl+D默认不会进入折叠块匹配，需先展开或换用全量方案
为什么 Alt+F3 不适合“按顺序”场景？
Alt+F3（Win/Linux）或 Ctrl+Cmd+G（macOS）是一键全选所有匹配项，它不保留顺序感，也不支持中途跳过。你无法知道哪个光标对应第几个出现位置，更没法“选到第 4 个就停”。它适合确定要改全部、且语义一致的场景（比如统一替换变量名），但不适合需要逐个确认、筛选或保留某处原状的情况。
真正容易被忽略的点：全选后如果发现某处不该改，你只能手动点掉那个光标——但鼠标单击会清空其他所有光标，只剩那一个；而用 Ctrl+K Ctrl+D 跳过，前提是得先有多个光标，也就是得从 Ctrl+D 或 Ctrl+Alt+G 启动多光标流程。
-
Alt+F3触发前，右下角状态栏不能亮着.*（正则模式），否则行为不可控 - 大小写敏感由右下角
Aa按钮控制，默认关闭（即User和user都会被选中） - 若快捷键失效，检查
Preferences → Key Bindings中find_all_under是否被插件覆盖
精准跳过某一个匹配项的操作链
核心逻辑不是“避免选中”，而是“先全量选中，再手动剔除”。这是唯一能兼顾效率与可控性的路径，尤其当你要改 12 处中的 11 处，且那 1 处位置不固定时。
标准操作流：Ctrl+D 两次（选中前两个）→ Ctrl+Shift+L（转为纯光标，方便定位）→ 方向键移到你想跳过的那个词上 → Ctrl+K Ctrl+D（移除当前光标）→ 剩余光标可同步输入。这比用鼠标点掉安全得多，也比删了重来省时间。
- 必须确保
find_in_selection未启用（Find → Find in Selection里不勾选），否则Alt+F3只在已选文本内找 -
Ctrl+K Ctrl+D是skip_current_selection命令，它只对当前光标有效，不影响其余光标状态 - 如果跳过之后还想补回某个位置，只能重新
Ctrl+D加选，或用鼠标点击（会清空其他光标，慎用）
整词匹配和语法感知的实际影响
Sublime 的“相同词”不是简单字符串相等。user_id 在 Python 文件里可能被识别为一个 token，但在 JSON 或 Markdown 里可能被拆成 user 和 id；a 这种单字母词，在多数 syntax 下默认不触发 Ctrl+D 匹配，因为被当作分隔符或关键字处理。
这意味着：同一段文本，在不同语言模式下，Ctrl+D 行为可能完全不同。不要假设“上次能用，这次一定行”。
- 检查右下角语言标识（如
Python、Plain Text），必要时手动切换 - 查看当前 syntax 的
word_separators设置（可在Preferences → Settings – Syntax Specific中查） - 临时切到
Plain Text模式测试，能排除语法高亮干扰，但会丢失语义保护（比如跳进字符串里）
Ctrl+D 逐个确认，还是该用 Alt+F3 全量出击——这个决策点藏在你对上下文语义是否信任。比如改函数参数名，要扫一眼每个出现位置是不是都在调用处；改 CSS 类名，得确认没混在 data-class 或注释里。漏判一次，就得重来。
