VSCode 的 Ctrl + → 不停在当前单词末尾，因其设计为跳到下一个单词起始位置；仅当光标已在单词开头时，首次按下才落于该单词最后一个字符右侧，此行为与 Ctrl + Shift + → 选中逻辑一致。
Ctrl + → 为什么不停在当前单词末尾？
VSCode 的 Ctrl + →（Windows/Linux）或 Option + →（macOS）默认行为是「跳到下一个单词起始位置」，不是「停在当前单词末尾」。所以：
- 光标在单词中间时，按一次
Ctrl + →会直接跳到**下一个单词开头** - 光标恰好在某个单词**开头**时，第一次按才会落在该单词**最后一个字符右侧**（即你想要的“末尾后”）
- 这个设计和
Ctrl + Shift + →（选中到单词末尾）完全对齐，不是 bug，是编辑语义一致性的体现
真正跳到当前单词末尾的可靠操作
想精准让光标落在当前单词最后一个字符之后（比如为插入符号、删词做准备），别依赖单次 Ctrl + →。推荐两种稳定方式：
- 先按
Ctrl + ←回退到当前单词开头，再按一次Ctrl + →，光标就稳稳落在末尾后 - 用
Ctrl + Shift + ←选中当前单词，再按→—— 这比记“两次右箭头”更直观、容错率更高
注意：如果光标停在 user_name 的下划线处，Ctrl + ← 可能只回退到 _name 开头，因为下划线被识别为分隔符；此时需确认当前语言模式是否正确（如 Python 文件没被当成 Plain Text）。
Ctrl + D 选中相同单词，为什么有时只加了两个光标？
Ctrl + D 不是全量匹配，而是从当前光标词出发，**向后线性查找下一个完全相同的单词**（区分大小写、全字匹配、受 editor.wordSeparators 影响）。常见失效原因：
- 中间夹了注释、字符串、或大小写不一致（如
User和user不匹配） - 光标停在标识符中间（如
getUserName的Name处），VSCode 按分隔符切词失败 - 语言模式未激活（.js 文件被识别为 Plain Text），导致分词逻辑退化
- 插件劫持了快捷键（如 Vim 插件重映射了
Ctrl + D）
想一次全选所有匹配项，用 Ctrl + Shift + L（macOS 是 Cmd + Shift + L），但注意它依赖已有选区，且超大文件（>5000 行）默认禁用。
多光标编辑时 Ctrl + Click 为什么跳转定义而不是加光标？
VSCode 默认把 Ctrl + Click 绑定为「转到定义」，不是「添加光标」。这是最常被误以为“快捷键失效”的场景。
- 临时解决：用
Ctrl + Alt + Click（Windows/Linux）或Cmd + Option + Click（macOS）手动加光标，无需改设置 - 长期调整：在设置里搜
editor.multiCursorModifier，改成ctrlCmd，但会把「转到定义」挪到Alt + Click - 列编辑必须用
Alt + 拖拽（Windows/Linux）或Option + 拖拽（macOS），快捷键无法自动推断列对齐位置
真正容易被忽略的是：列编辑前，得先确保目标列的字符位置对齐（比如都用空格缩进而非混合 Tab/Space），否则拖出来的光标会歪斜。
