ctrl+g/cmd+g是唯一原生支持行列定位的快捷键，但列号仅提示“尽量去该位置”，实际光标会就近吸附（如行不足45列则停行尾），受制表符展开、软换行、折叠及语言服务加载状态影响。
Ctrl+G（Windows/Linux）或 Cmd+G（macOS）是唯一原生支持行号+列号精准定位的快捷键，但它的“精准”是有条件的：列号只影响光标水平位置，不保证视觉可见；跳转后是否真落在目标字符上，取决于语言模式、换行符、折叠状态和渲染机制。
为什么输入 123:45 后光标没停在第 45 列？
VS Code 的列号从 1 开始计数，但实际对齐逻辑不是“硬跳”，而是“就近吸附”：
-
123:45表示“尝试把光标放在第 123 行、逻辑列 45 的位置”，但如果该行只有 30 个字符，光标会自动落到行尾（即第 30 列） - 如果该行含制表符（
\t），列计算按tabSize设置展开（默认 4），123:7可能落在第 2 个 tab 后第 3 个字符上，而非字面第 7 个字节位置 - 启用
editor.wordWrap: "on"时，长行视觉折行，但列号仍按原始单行计算——此时123:45指的是折行前的第 45 列，不是你看到的“第二屏”的第 45 列 - 某些语言扩展（如 Prettier、ESLint 自动修复）可能在跳转后立即触发格式化，导致光标位置偏移
code -g 命令行跳转中列号为何有时失效？
终端执行 code -g "file.ts:123:45" 时，列号解析比 GUI 更严格，且受路径解析链影响：
- 路径必须用英文双引号包裹，否则空格或特殊字符会导致列号被截断或忽略（例如
code -g src/file.ts:123:45在含空格路径下会失败） - 列号必须是纯数字，不能带前导零（
123:045会被当作无效格式静默降级为123） - 远程开发（SSH/WSL）场景下，
code -g实际由本地 CLI 转发指令，列号信息可能在协议层丢失，尤其当远程服务器未运行完整 VS Code Server 时 - 若文件尚未被语言服务加载（比如刚打开的大日志文件），列定位会退化为行定位，
:45部分被丢弃
点击行号 + 拖拽能否实现行列精确定位？
不能。点击行号本质是“跳转到该行首”，与 Ctrl+G 输入 123 效果一致；拖拽行为完全由鼠标事件驱动，VS Code 不提供“按住 Shift 点击行号跳列”的交互路径：
- 行号区域点击只响应单击，且仅在编辑器聚焦、无补全弹窗、非多光标状态下生效
- 即使你拖选了某行中的一段文本，再点行号，光标仍落在该行开头，不会记住上次选中的列位置
- 想复用列位置，只能靠
Ctrl+G输入历史（按上下箭头调出最近输入）或命令面板里重复执行Go to Line - 某些 Vim 扩展（如 vscode-neovim）覆盖了原生行为，此时
123|或:123|45可能生效，但这属于扩展逻辑，非 VS Code 内置
真正决定“精准”的从来不是输入格式，而是当前文档的状态：是否已解析、是否被折叠、是否启用了软换行、甚至键盘布局是否把冒号映射成了其他符号。列号只是提示，不是契约——它告诉你“尽量去那儿”，而不是“保证抵达”。
