Ctrl+G（Windows/Linux）或Cmd+G（macOS）是唯一原生、稳定、无需扩展的跳转方式，需确保焦点在编辑器内、输入格式严格（如123或123:45）、按Enter确认，缺一即静默失败。
Ctrl+G（Windows/Linux）或 Cmd+G（macOS）是唯一原生、稳定、无需扩展的光标跳转指定位置方式，但必须满足三个硬性条件：焦点在编辑器内、输入格式严格、按 Enter 确认。漏掉任一环节，就会静默失败——不报错、不动光标、也不提示。
为什么 Ctrl+G 输入后光标没动？
不是快捷键坏了，而是它对上下文极度敏感：
- 光标必须落在代码编辑器区域；停在终端、搜索框、命令面板或侧边栏时，
Ctrl+G完全不触发 - 输完数字必须按
Enter——只输123不回车，光标就卡在输入框里 - 格式必须是纯数字（
123）、行:列（123:45，冒号为英文、无空格）、或范围（123-125）；写成123,45、123：45（中文冒号）、123（开头空格）都会静默忽略 - 某些 Vim 扩展或远程插件会劫持该快捷键；可临时禁用全部扩展验证是否冲突
123:45 跳不到第 45 列？列号计算逻辑是什么
VS Code 的列号从 1 开始计数，但“跳到第 45 列”本质是“尝试吸附到逻辑列 45”，实际落点受多种因素影响：
- 若该行只有 30 个字符，光标自动停在行尾（第 30 列），不会报错
- 制表符（
\t）按editor.tabSize展开计算；123:7可能落在第 2 个 tab 后第 3 个字符上，而非字面第 7 字节 -
editor.wordWrap: "on"时，视觉折行不影响列号——123:45指的是原始单行的第 45 列，不是你看到的“第二屏”的第 45 列 - 语言服务未加载完成（如刚打开大日志文件）时，列定位会退化为行定位，
:45部分被丢弃
从终端快速跳转到某文件某行列：用 code -g 而不是 code --goto
调试日志或 Git 输出中看到 src/api.ts:42:8，直接在终端执行：
code -g "src/api.ts:42:8"
关键细节：
-
-g必须紧贴code命令，写成code --goto或code --go-to无效 - 路径含空格或特殊字符时，**必须用英文双引号包裹整个参数**；漏掉引号会导致解析失败，VSCode 可能打开空白窗口或报
command not found: code - 列号不能带前导零（
42:008会被静默降级为42） - 远程开发（SSH/WSL）场景下，
code -g必须在远程终端中执行；本地终端运行只会打开本地实例
状态栏点击 Ln X 是最抗干扰的备用方案
右下角显示 Ln 35, Col 8 时，直接点击 Ln 35 部分，输入新行号后按 Enter。这个操作绕过所有快捷键拦截层，适合以下场景：
- 远程 SSH 连接延迟高，
Ctrl+G响应慢或失效 - 输入法或系统快捷键（如 macOS 的 Mission Control）劫持了
Cmd+G - 文件处于 diff 视图、GitLens blame 行等装饰状态，
Ctrl+G无法跳到真实源码行
但它同样受折叠和软换行影响：目标行若被折叠，光标会落在折叠标题行；启用 wordWrap 时，行号仍是逻辑行号，不是视觉折行序号。
