Ctrl+G/Cmd+G是VSCode唯一原生支持行列精确定位的方式，输入“123:45”可跳转至第123行第45列（列号从1开始），格式必须严格、焦点需在编辑器内，否则静默失败。
Ctrl+G 输入 123:45 是唯一原生支持行列精确定位的方式
VSCode 不提供单独跳转到列的快捷键，Ctrl+G（Windows/Linux）或 Cmd+G（macOS）是唯一能同时指定行与列的内置操作。输入格式必须是 行号:列号，例如 42:8，回车后光标会落在第 42 行第 8 个字符位置（列号从 1 开始计数，不是 0）。
常见错误现象：输入 42,8、42 8、42：8（中文冒号）或开头有空格，都会静默失败——界面无提示、光标不动、也不报错。
-
列号超出该行长度时，光标自动停在行尾，不会报错或截断 - 多光标模式下，
Ctrl+G仍只移动主光标，其余光标位置不变 - 如果文件启用了
editor.wordWrap: "on"，视觉折行不影响列号计算——列始终按原始字符串索引算
命令行用 code -g 打开文件并跳转到行列需严格包裹路径
从终端调试日志或 Git 输出中快速切入某处，code -g 是唯一可靠方案。关键点在于：-g 必须紧贴 code 命令，不能写成 code --goto 或 code --go-to，后者已弃用或无效。
路径含空格或特殊字符时，必须用英文双引号包裹整个参数，例如：code -g "src/utils.ts:102:6"。漏掉引号会导致解析失败，VSCode 可能打开空白窗口或报错 command not found: code。
- 如果终端提示
command not found: code，说明 CLI 未注册：macOS 在菜单栏Code → Install 'code' command in PATH；Windows 在设置中搜索Shell Command并启用 -
code -g中的列号也是从 1 开始，:1表示行首第一个可见字符位置 - 远程开发（Remote-SSH）场景下，
code -g必须在远程终端中执行，本地终端运行只会打开本地实例
点击行号跳转失效的三个隐藏前提
很多人习惯鼠标点击左侧行号跳转，但这功能不是“点了就跳”，它依赖三个隐性条件同时满足：
- 编辑器必须获得焦点——如果当前光标在终端、搜索框或命令面板里，点击行号会新增光标而非跳转
- 不能有补全弹窗（如 IntelliSense 下拉框）遮挡行号区域，否则点击被拦截
- 多光标激活状态下，点击行号会在该行插入新光标，而不是移动主光标
更隐蔽的问题：GitLens 的 inline blame、diff 视图、语言服务器注入的 TODO 行等装饰内容，会占据视觉行但无真实文件位置。此时点击的“行号”实际指向装饰层，Ctrl+G 输入相同数字也无法跳到对应源码行——因为那根本不是逻辑行。
行号不准？先确认你看到的是逻辑行还是视觉行
状态栏显示的 Ln 123 和你 Ctrl+G 输入的 123 不一致，大概率不是 VSCode bug，而是换行符或装饰层干扰。
文件若含 Unicode 换行符（如 \u2028、\u2029），VSCode 会将其识别为独立行，导致总行数比预期多。标准换行符只有 \n 和 \r\n。
- 验证真实行数：打开命令面板（
Ctrl+Shift+P），运行Developer: Toggle Developer Tools，在 Console 里执行editor.getModel().getLineCount() - 启用
editor.cursorSurroundingLines后，跳转目标行可能被“推”出可视区顶部——不是没跳，是视图滚动策略优先保证光标上下留空 - 折叠代码块内部的目标行，
Ctrl+G会把光标落在折叠标题行上，需手动展开才能看到内容
真正卡住人的从来不是快捷键记不住，而是误以为“焦点、格式、装饰层、换行符”这四个地方可以随便忽略——少一个条件，Ctrl+G 就变成假装在工作。
