ctrl+g没反应大概率是插件劫持快捷键，需检查key bindings或禁用sidebarenhancements等插件；输入行号须为纯数字，空格或字母会导致查找而非跳转；原生不支持行列定位，大文件首次跳转因构建行索引会延迟。
Ctrl+G 输入行号没反应？检查是否被插件劫持了快捷键
sublime 默认的 Ctrl+G（windows/linux）或 Cmd+G（macos）是跳转到指定行的核心操作，但很多用户发现按了没反应——大概率是装了 SideBarEnhancements、AdvancedNewFile 或某些 git 插件，它们悄悄把 Ctrl+G 绑定到了别的命令上。
实操建议：
- 打开
Preferences → Key Bindings，左侧是默认键位，右侧是用户自定义键位，搜索"ctrl+g"看是否有覆盖项 - 临时禁用插件验证：菜单栏
Preferences → Package Control → Disable Package，逐个关掉可疑插件再试Ctrl+G - 如果确认被占用，可在用户键位文件里加一行明确绑定：
[{"keys": ["ctrl+g"], "command": "goto_line"}]
输入 123 跳到了第 12 行？注意行号后不能带空格或字母
Sublime 的 goto_line 命令对输入格式非常敏感：只接受纯数字，开头或结尾多一个空格、一个点、甚至中文全角数字都会失败，此时它会退化成“查找当前光标所在行的文本”，看起来像随机跳转。
常见错误现象：
- 输
100（末尾有空格）→ 跳到含 “100” 的某行，不是第 100 行 - 输
100a→ 搜索字符串 “100a” - 输
0100→ 正常跳转到第 100 行（前导零不影响）
正确做法：弹出输入框后，直接敲数字，回车即可；不需要加冒号、等号或任何符号。
想跳到 123:45（第 123 行第 45 列）？原生不支持，得靠插件或命令行参数
Sublime 原生 Ctrl+G 只处理行号，不解析列偏移。虽然部分插件（如 LineJumper）或外部工具（如 CLI 启动时传 subl file:123:45）能实现行列定位，但编辑器内交互式输入不认冒号语法。
使用场景和替代方案：
- 日常调试查日志时，通常只需行号，列定位意义不大
- 需要精确列定位，可先
Ctrl+G跳到行，再用Ctrl+Right或鼠标点击微调 - 自动化脚本调用 Sublime 时，用命令行参数最可靠：
subl --command "goto_line {"line": 122, "column": 44}"
大文件（>10MB）跳转变慢？不是卡死，是 Sublime 在构建行索引
Sublime 对超大文件首次跳转会有明显延迟，尤其当文件未被缓存过。这不是 bug，而是它在后台同步构建“行起始位置”的内存索引——每行都要扫描换行符，文件越大，首跳越慢。
性能影响与缓解方式：
- 第二次跳同一文件的任意行，基本无延迟
- 避免用 Sublime 编辑日志/导出数据等纯查看型超大文本，改用
less或 VS Code 的“large file optimizations” - 如果必须用，可提前打开文件闲置几秒，让它完成索引预热
行号跳转本身没有精度损失，但别指望在 100MB 的 CSV 里秒进第 999999 行——它得先把前面所有换行符数完。