alt+b/alt+f是atom原生支持的emacs风格单词级光标移动快捷键：alt+b向左跳至上一个单词开头，alt+f向右跳至下一个单词开头，单词定义为\w+序列，无需插件或配置。
Alt+B / Alt+F 是默认按单词移动的快捷键
Atom 原生支持 Emacs 风格的单词级光标移动，无需装插件或改配置：Alt+B 向左跳到上一个单词开头，Alt+F 向右跳到下一个单词开头。这个“单词”定义为由字母、数字、下划线组成的连续序列（即 \w+），所以 user_name 算一个词，APIResponse 也算一个词。
常见误操作是按了 Ctrl+←/→——那只是模拟方向键，不触发单词跳转；或者用 Ctrl+Shift+←/→，那是「选择+跳转」，会连带选中文本，不是纯移动。
- macOS 用户注意：
Alt键在多数键盘上对应Option，不是Cmd - 如果没反应，检查是否被输入法或系统快捷键劫持（如 macOS 的 Spotlight 默认占
Cmd+Space，但Alt+B/F一般不受影响） - 某些语言包（如 Python 或 JSX）可能覆盖该行为，可临时切到 Plain Text 语法模式验证是否是语法插件干扰
vim-mode-plus 下要用 b / w 而不是 Alt+B/F
一旦启用 vim-mode-plus，原生 Alt+B/F 就失效了，因为 vim 模式接管了所有普通模式下的移动命令。b 和 w 成为真正按单词跳转的主力：
-
b：跳到**当前单词开头**（若光标在词中）或**上一个单词开头**（若光标在空白处） -
w：跳到**下一个单词开头**（跳过中间空白） -
ge：跳到**上一个单词结尾**（比b更精准定位末尾） - 加数字前缀可重复，如
3w向右跳三个单词
注意：w 和 e 的行为差异很关键：w 停在单词首字符，e 停在单词尾字符；e 不跨空白，w 会跨过空格再找下一个词头。
想让单词边界更智能？得改正则或换插件
默认的单词划分对驼峰命名（camelCase）或连字符命名（kebab-case）不友好——camelCase 整体被当做一个词。如果需要按大小写或连字符拆分，有两条路：
- 手动改
editor.wordRegex配置项：在 Atom Settings → Core → Editor → Word Regex 里填入更细粒度的正则，比如/[A-Za-z0-9_]+|[A-Z][a-z]+/g，但会影响全局搜索和Ctrl+D的匹配逻辑 - 装
vim-mode-plus-subword-movement插件：它把gb/gw绑定为“子词”移动（camelCase中的camel和Case分开跳），不影响原有b/w - 别指望
highlight-selected或easy-motion改变单词定义——它们只做高亮或跳转，不参与光标移动的语义解析
为什么 Ctrl+←/→ 有时跳得不准？
Ctrl+← 和 Ctrl+→ 在 Atom 中其实是“软绑定”，底层调用的是 editor:move-to-next-word-boundary 和 editor:move-to-previous-word-boundary。它依赖当前语法的语言服务判断边界，而非纯正则。
典型问题：
- 在 JSON 或 YAML 里，
"key": "value"中的冒号、引号会被当作分隔符，Ctrl+→可能停在:后而不是"value"开头 - JSX 中
<div classname="foo">，光标在 <code>className里按Ctrl+→可能直接跳到=后，因为属性名和值被语法解析器视为不同 token - 此时不如切回 Normal 模式按
w，或用Alt+F（更稳定，不依赖语法高亮）
真正稳定的方案永远是：明确自己处于哪种模式（原生 / vim / 语言专属），然后用对应体系下的标准命令，别混用。
