Ctrl+G是唯一可靠、无需插件、对未保存文件也生效的行跳转方式；按了没反应多因焦点不在编辑区或被插件劫持，输入超出行数则静默跳至末行。
Ctrl+G 是唯一可靠、无需插件、对未保存文件也生效的跳转方式。其他快捷键（比如 Ctrl+P 输入 file.js:123）本质是文件搜索，不是行跳转；Ctrl+R 只查当前文件符号，不认行号；想精准落到某一行，别绕弯，就用 Ctrl+G。
为什么 Ctrl+G 有时按了没反应
不是快捷键记错了，是焦点或绑定被 hijack 了：
- 光标必须在编辑器内容区——如果聚焦在设置页、控制台、侧边栏或搜索面板，
Ctrl+G完全静默 - 插件（尤其是
vim-mode-plus或atom-ide-ui）可能覆盖原生绑定，导致按下去执行的是vim-mode-plus:go-to-line而非editor:go-to-line - 验证方法：打开 Key Binding Resolver（
Ctrl+./Cmd+.），再按Ctrl+G，看右侧是否显示绑定到editor:go-to-line - 临时修复：Settings > Keybindings 搜索
editor:go-to-line，点铅笔重绑为Ctrl+G - 长期解决：在
keymap.cson里加这一行：'atom-text-editor:not([mini])':<br> 'ctrl-g': 'editor:go-to-line'
输入行号后跳错位置的常见原因
Atom 的 editor:go-to-line 行为有明确兜底逻辑，不是 bug：
- 输
100回车却跳到最后一行？说明当前文件总行数 - 输
42:8却没停在第 8 列？确认列号是从 1 开始计数（不是 0），且该行至少有 8 个字符（含空格） - 大文件（>10MB）下跳转后光标卡顿半秒？这是渲染延迟，不是失败；连按会加重卡顿，等第一次响应完成再操作
- 输入后直接按 Esc 可取消，不会误跳；按 Enter 才确认
命令行启动时精确定位到行列
终端里调用 atom 命令也能带行列参数，但前提是 atom 命令已正确注册进 PATH：
- 先验证：
atom --version有输出才算配置成功；macOS 常见问题是软链接缺失，需手动sudo ln -s /Applications/Atom.app/Contents/Resources/app/atom.sh /usr/local/bin/atom - 打开并跳转到第 42 行：
atom script.py:42 - 进一步定位到第 42 行第 8 列：
atom script.py:42:8 - 路径含空格必须加英文双引号：
atom "My Project/src/index.js":15 - 多个文件可一次打开：
atom file1.js:15 file2.css:30:4
真正容易被忽略的是：所有基于 Ctrl+G 的跳转，只作用于当前激活标签页，不跨文件。这不是限制，而是设计——它意味着你永远不必担心“跳到哪去了”，只要看清当前是哪个文件，输入就绝对落在那里。
