VS Code中方向键行为因上下文而异：编辑器内正常移动光标，终端中被shell接管用于命令行导航，多光标下仅主光标响应，Home默认跳物理行首而非逻辑行首，需用cursorHome命令实现后者。
VSCode 中单字符移动看似最基础，但实际行为受平台、输入法、语言扩展甚至终端模式影响极大——→ 键在编辑器里跳一个字符，在集成终端里可能被 shell 拦截为命令历史导航。
方向键在编辑器 vs 终端中行为完全不同
你在编辑器里按 →，光标向右移一列；但在 Terminal 面板里按同样的键，bash/zsh 会把它当作「命令行向前移动一个字符」，而 PowerShell 可能直接忽略——这不是 VSCode 的 bug，是 shell 自己的行编辑器（readline / PSReadLine）在接管输入流。
- 终端中想强制让方向键生效，得先确认当前 shell 是否启用行编辑：bash 下执行
bind -v | grep enable，输出含enable-keypad才算正常 - Windows Terminal 或 iTerm2 中启用了「应用光标键模式」后，
↑可能发的是\x1b[A而非普通 ASCII，VSCode 无法识别，表现为按键无反应 - 多光标下，方向键只移动主光标，其余光标原地不动——这不是限制，是设计：避免批量移动引发意外覆盖
Ctrl+方向键跨单词移动时的边界判定逻辑
Ctrl+→ 不是简单按空格切分单词，而是基于 Unicode 字符类别 + 编程语言 token 边界。比如在 user_name2 中，它会停在 user_ 后、name2 后；但在 user-name2 中，连字符被视作分隔符，停在 user- 后、name2 后。
- JavaScript/TypeScript 文件中，
myObj.propName()会被切成myObj→.→propName→(→)，括号单独成“词” - Python 文件中，
self._private_var的下划线不打断单词，Ctrl+→会一次性跳过整个标识符 - 如果按一次
Ctrl+→没反应，检查是否处于注释或字符串内：部分语言扩展（如 YAML）会禁用跨词移动以避免误切字面量
Home/End 键为什么总停在缩进位置而不是代码起点
这是最常被误解的一点：Home 默认跳的是「物理行首」（第 0 列），不是「逻辑行首」（第一个非空白字符前）。所以面对 return true;，它停在 4 个空格前，而非 return 前。
- 真正跳逻辑行首的命令是
cursorHome，需手动绑定快捷键（如 Windows/Linux 用Ctrl+Shift+Home） - macOS 上
Cmd+←是唯一原生支持逻辑行首的组合，且不会被 Pylance、YAML 等扩展劫持 - 若绑了
cursorHome但没效果，先关掉多光标模式——该命令在多光标下仅作用于主光标 - 折叠代码块内仍有效：函数体被折叠时，
cursorHome仍能精准落到{前，而非折叠提示行的开头
真正麻烦的不是键位记不住，而是不同上下文（编辑器/终端/多光标/折叠块）下同一组按键触发完全不同的底层命令——你得先判断当前焦点在哪，再决定该信 Home 还是 cursorHome，否则光标永远停在你不想让它停的地方。
