Ctrl+D按顺序选中下一个未修改的相同单词，光标需位于单词有效字符上；全选所有匹配项应使用Ctrl+Shift+L，且依赖当前选区或光标位置。
Ctrl+D 按顺序选中下一个相同单词
VSCode 里真正用来“找下一个相同单词”的快捷键是 Ctrl+D（Windows/Linux）或 Cmd+D（macOS），不是查找面板里的操作。它不跳转、不替换，只在当前文件内按顺序加光标。
常见错误现象：Ctrl+D 按了没反应，或只选中一次就停住——大概率是光标没落在单词内部（比如停在空格、引号外、点号后），或者你之前手动改过某处匹配项，VSCode 默认跳过所有已修改的上下文。
- 必须先让光标落在目标词的任意字母、数字或下划线字符上（如
userId中的u或d） - 双击选中后再按
Ctrl+D，会以整个选区为基准匹配，但若选区含空格或标点（如"user"），匹配可能失败 - 已修改过的实例（比如把
user改成userName）会被自动跳过，后续Ctrl+D不再考虑它 - 想跳过当前匹配项继续往下找？按
Ctrl+K再按Ctrl+D - 误加了光标？按
Ctrl+U撤销上一个，连按可逐步退回去
Ctrl+Shift+L 一次性全选所有匹配项
如果你要的不是“下一个”，而是“全部”，Ctrl+Shift+L 才是更直接的选择。它不逐个确认，直接把当前光标所在词的所有匹配位置都加上光标。
但它对触发条件很敏感：光标必须落在单词的有效字符上，否则会匹配失败；语言模式也影响分词结果（比如 user_name 在 Plain Text 模式下可能被拆开，在 JavaScript 模式下才识别为一个词）。
- 默认区分大小写：
UserId≠userid，如需忽略，先用Ctrl+F搜索，点搜索框右上角Aa关闭大小写匹配，再按Ctrl+Shift+L - 如果已手动选中一段文本（比如带引号的
"user"），Ctrl+Shift+L就以该段文本为搜索目标，而非仅单词边界 - 它不跨文件，也不支持正则；真要处理
api/v1/\w+这类模式，得进Ctrl+H开启.*模式再按Alt+Enter
为什么 Ctrl+F + Alt+Enter 更安全
当你不确定是否要改所有匹配项，或者想预览位置再动手，Ctrl+F 输入关键词后点右下角“全部选中”图标，或直接按 Alt+Enter，比盲按快捷键更可控。
这个流程天然高亮所有匹配项，你能一眼看出哪些在字符串里、哪些在注释中、哪些大小写不一致——避免误改不该动的地方。
- 搜索框里输入
id，Ctrl+Shift+L会同时选中user_id、order.id、"id"里的id；而Ctrl+F配合Whole Word（\b）开关能精准控制范围 -
Alt+Enter选中后，光标不会自动进入编辑状态，你可以先检查再输入，不容易手滑 - 如果匹配项太多导致卡顿，VSCode 会限制默认选中数量（通常 200 以内），这时
Ctrl+F的分页滚动反而更稳
容易被忽略的配置和边界情况
很多问题其实出在编辑器配置或语言模式上，而不是快捷键本身失效。
editor.wordSeparators 决定了什么是“单词边界”。默认值包含 ./\ 等符号，所以 user.name 里的 name 会被单独识别；但如果你删掉了 .，Ctrl+D 就可能把整个 user.name 当作一个词来匹配。
- 不同语言模式对下划线、连字符处理不同：JSON 模式下
user_name是一个词，Plain Text 下可能是两个 - 鼠标点击时不小心拖动了光标，导致起始位置偏移，
Ctrl+D就从错的位置开始找 - 插件（比如 Prettier、ESLint）可能在保存时自动格式化，悄悄改了某处文本，导致后续
Ctrl+D跳过那个位置 - 多光标状态下按方向键会同步移动所有光标，但按 Backspace 或 Delete 只删当前光标所在位置的内容，容易漏删
实际用的时候，别死记快捷键，先看光标落哪儿、当前语言模式是啥、有没有改过中间某处——这些细节比按键次数更重要。
