Sublime没有“上一个修改过的文件”概念，Ctrl+Tab仅按最近激活顺序切换标签页，不记录修改状态；可靠方案为Ctrl+Tab、BufferScroll插件或Ctrl+Shift+T恢复刚关闭文件。
Sublime 没有“按修改状态”或“按打开顺序”智能排序的标签页切换逻辑；Ctrl+Tab 是唯一原生、可靠、无需插件的多文件跳转方式，但它只按最近激活时间倒序排列，不是按修改与否。
Ctrl+Tab 切换本质是「最近激活栈」，不是「修改文件栈」
Sublime 的 Ctrl+Tab（Windows/Linux）或 Cmd+Tab（macOS）不关心你是否保存、是否编辑、是否加了 * 脏标记。它只记录你「最后一次把焦点切到哪个 tab 上」——刚点过的、刚用 Ctrl+P 打开的、刚从侧边栏双击的，都会排在最前。
- 如果你连续编辑 A → B → C，
Ctrl+Tab会先回到 B，再回到 A - 但如果你中间切去终端插件、弹出命令面板
Ctrl+Shift+P，再切回来，B 和 C 的顺序可能被干扰 - 关闭一个 tab 后，
Ctrl+Tab不会自动跳过它，而是停在上一个有效 tab —— 但不会提示你“这个已关”
为什么 Ctrl+P 搜 “recent” 或 “modified” 总是失败
因为 Sublime 原生命令里压根没有 recent_modified_files 这类命令。所有带 “recent” 字样的插件（如 SublimeHistory）或命令面板搜索结果，实际记录的是：buffer 切换历史、光标落点、或文件名匹配缓存，而非 Git 级别的修改状态。
-
Ctrl+P输入recent→ 匹配的是命令名（如Recent Files），不是文件修改时间 -
Ctrl+P输入modified→ 无任何原生命令响应，插件也极少实现该语义 - 所谓“最近修改的文件”，Sublime 不索引、不标记、不暴露 API —— 它连文件是否被修改都懒得管，更别说排序
真要基于修改状态跳转，只能靠 Git + Ctrl+P 组合拳
这是目前唯一稳定、精准、不依赖插件的方案，前提是项目已用 Git 管理且文件已 git add 过。
- 终端执行
git status --porcelain，输出类似M src/utils/api.js（M 表示 modified） - 复制第一行的文件路径（如
src/utils/api.js） - 回 Sublime 按
Ctrl+P，粘贴路径后回车 —— 它会直接打开该文件并聚焦 - 如果文件没被 Git 跟踪（比如新创建未
add），git status不显示，这条路就断了；此时只能靠BufferScroll插件缓存的 buffer 列表，但它仍不区分“改过”和“只看过”
别信“跳转堆栈能记住你刚改的那行”
Ctrl+Alt+-（jump_back）和 Ctrl+U（jump_back_on_stacked_jump）看起来像“返回编辑点”，但它们只记光标位置，不记文件维度的修改行为。你打字、删空格、粘贴一行代码，这些动作本身不会生成新的跳转点 —— 只有你点击、F12、Ctrl+Click、Ctrl+P 选中某行，才会入栈。
所以当你想“回到刚才改的那行”，而那一行在另一个文件里，jump_back 很可能带你回到当前文件里上次点击的位置，而不是目标文件。这个细节，90% 的用户第一次踩坑时都没意识到。
