最常见原因是文件编码或换行符异常；vscode默认按\n计行，若含单独\r、未识别bom或utf-16编码错误，行数会偏移，导致输入100实际跳到97或102行。
Ctrl+G 跳转行号为什么有时不准？
最常见原因是文件编码或换行符异常。VSCode 默认按 \n 计算行号，但如果文件含 \r 单独出现、BOM 头未识别，或用 UTF-16 编码但未正确声明，行计数就会偏移——你输 100，光标实际落在第 97 或 102 行。
验证方法：打开文件后看右下角状态栏显示的编码和换行符（如 UTF-8 + CRLF）。若显示 Auto 或 Unknown，手动点击它并选 Reopen with Encoding 试 UTF-8；再检查是否所有换行都是 \r\n（Windows）或 \n（Unix/macOS），避免混用。
- 大日志文件首次加载时，VSCode 可能延迟解析换行，
Ctrl+G仍可用，但跳转位置可能滞后一两行 - 只读临时文件（如通过
code -r file.txt打开）不影响Ctrl+G，但部分插件的后续操作（如高亮匹配）可能不触发 - 输入
100:5跳列时，列数从 1 开始计，且某些语言扩展（如 LaTeX）对列定位响应较慢，需等语法高亮就绪
全局搜索 Ctrl+Shift+F 怎么避免跳转错行？
搜索结果点击跳转本身可靠，但“视觉上看到的行”和“实际跳转的行”不一致，往往是因为正则贪婪匹配导致行被折叠或截断显示。比如搜 if.*:，匹配到 if condition and other_thing:，但面板只显示前半截，你以为是第 42 行，点进去发现光标在第 43 行开头。
解决办法不是关正则，而是盯住状态栏：只有显示 “N results”（非 0）时，跳转才真正基于命中行。如果开了 .* 但状态栏写 “0 results”，说明正则语法有误或未匹配，此时点击结果只是默认跳到文件首行。
- 启用
Match Case或Regex时，务必确认右上角开关是蓝色激活态，灰色=未生效 - 跨文件搜索时，用
include:*.py限定类型，比盲目扫全项目更稳——减少因文件过多导致的索引延迟 - 搜索含换行的内容（如多行注释），必须用
\n显式写进正则，不能指望 UI 输入框自动换行
Bookmarks 插件标记行 vs Ctrl+G 输入行号，选哪个？
本质区别在于：一个是“语义锚点”，一个是“坐标定位”。Ctrl+G 快、无依赖、适合错误日志里带行号的场景；Bookmarks 插件（快捷键 Ctrl+Alt+K）适合你反复修改同一逻辑块、但行号会随增删代码漂移的情况。
比如你在重构函数体，加了 3 行日志，原第 87 行变成第 90 行——Ctrl+G 87 就失效了，但书签还在那儿，点一下就到最新位置。
- 书签默认不跨工作区持久化，关 VSCode 后重开仍保留，但换台机器或重装插件会丢
- 不要依赖书签跳转来替代符号导航（
Ctrl+Shift+O）：前者记位置，后者记名字，函数重命名后书签还在旧行，符号导航自动更新 -
Ctrl+Alt+J/Ctrl+Alt+L在书签间跳，比反复Ctrl+G更顺手，尤其当你要对比 3–4 个散落位置时
LaTeX 反向查找后代码行不在视图中央？
这不是跳转失败，而是 VSCode 原生不居中当前行。Synctex 把光标准确定位到行，但滚动逻辑由编辑器控制，默认停在顶部/底部取决于之前视图状态。
必须靠 Center Editor Window 这类插件补足。关键不是装插件，而是配对延迟参数："centerEditorWindow.autoCenterDelay": 100 ——太小（如 10ms）Synctex 还没完成跳转就居中，太大（如 500ms）人眼已察觉卡顿。
- 别绑定
Ctrl+L给居中，它和 LaTeX 编译快捷键冲突；Alt+C是单手可按、低冲突的优选 -
"when": "editorTextFocus && !editorReadonly"这条条件必须加，否则在只读 PDF 预览页里误触发，会导致编辑器莫名其妙滚动 - 如果用了远程开发（SSH/WSL），插件需在远程端安装，本地装无效
