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 后。

VSCode

避免常见的 VSCode 错误——设置冲突、调试器配置和扩展冲突。

下载

• 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，否则光标永远停在你不想让它停的地方。