ctrl+tab默认按mru顺序切换而非标签栏顺序；改用next_view_in_stack可实现线性切换；ctrl+1～9按分组内物理位置响应；最可靠的是ctrl+p模糊搜索文件名。
Ctr+Tab 默认不按标签栏顺序切换，这是设计使然，不是快捷键坏了——想线性切换就得换命令或换策略。
为什么 Ctrl+Tab 总是跳到“不该去”的标签？
Sublime 的 next_view 和 prev_view 命令默认走 MRU（Most Recently Used）逻辑：你上一秒点过的文件，不管它在第几个位置，下次 Ctrl+Tab 就优先跳过去。这不是 bug，但会导致三类典型问题：
- 刚关掉一个标签（比如用
Ctrl+W），再按Ctrl+Tab可能闪回一个空视图（它还在 MRU 栈里，只是没渲染） - 命令面板（
Ctrl+Shift+P）、无名文件（Untitled）、查找框都算“视图”，参与排序但不显示在标签栏，你按着Ctrl+Tab却找不到目标 - 中文输入法在全角模式下常劫持
Ctrl+Tab，表现为按了没反应——先切回英文输入法再试
怎么改成从左到右线性切换（类似 Chrome）？
用 next_view_in_stack 替代 next_view，它只看标签栏物理位置，不理会你最近点过谁。操作很简单：
- 打开
Preferences → Key Bindings - 在右侧用户配置区粘贴以下内容（注意 JSON 格式和引号）：
[ {"keys": ["ctrl+tab"], "command": "next_view_in_stack"}, {"keys": ["ctrl+shift+tab"], "command": "prev_view_in_stack"} ]
- 保存即生效，无需重启
- 注意：
next_view_in_stack不会跳过刚关掉但仍在栈里的标签，所以有时会“闪回”一次——多按一下就过去了
Ctrl+1～Ctrl+9 为什么经常失灵？
这些快捷键绑定的是“当前 Group 内从左往右的第 N 个位置”，不是文件本身，也不是全局索引。常见失效原因：
- 开了分屏（比如
Ctrl+Alt+2左右两列），Ctrl+3只在当前列找第三个标签，另一列的同位置标签完全不响应 - 拖拽重排过标签，
Ctrl+3仍指向“第三个位置”，不是“原来第三个文件” - 超过 9 个标签后，没有原生
Ctrl+0跳最后，也不能自定义Ctrl+10——数字键只支持 1–9 - 临时视图（如命令面板、无名文件）不占位，也不响应数字键
真正可靠、不依赖记忆的切换方式是什么？
别硬记位置，用 Ctrl+P（Windows/Linux）或 Cmd+P（macOS）。它不走 MRU，也不看标签是否还开着，而是模糊匹配已打开文件名（含路径）：
- 输
user，立刻列出所有含该词的已开标签，带:标识 - 输
:32直接跳当前文件第 32 行；输@get_user可跳函数定义（需符号索引就绪） - 哪怕你刚关掉
settings.json，Ctrl+P输setting仍能立刻重新打开 - 它不受插件干扰，也不依赖当前 Group 或窗口焦点——只要文件在当前窗口里打开过，就能搜到
MRU 的不可预测性和数字键的位置漂移，本质都源于 Sublime 把“视图”和“标签栏展示”做了分离。真正省时间的不是更快地按错三次 Ctrl+Tab，而是用 Ctrl+P 一次命中。
