Ctrl+Tab 始终按 MRU（最近使用顺序）切换，与标签栏是否多行无关；多行仅影响视觉布局，VSCode 切换逻辑只依赖激活时间戳，不感知物理排列，预览标签默认不入 MRU 但可能被临时加入，拖拽和 Ctrl+1～9 会重排 MRU，导致历史与视觉顺序脱钩。
Ctrl+Tab 依然按 MRU 切换，和是否多行无关
多行标签栏只是视觉上把标签“堆高”，VSCode 的切换逻辑完全不感知行数。不管是一行还是三行，Ctrl+Tab 始终唤出最近使用顺序（MRU）面板，不是从左到右扫第一行、再扫第二行——它压根不看物理排列，只看激活时间戳。
常见错误现象：Ctrl+Tab 按着按着跳进一个根本没注意过的文件（比如刚从搜索结果点开又关掉的 utils.ts），或者卡在预览态标签（斜体）反复进出，造成“跳错”“卡顿”感。
- 预览标签（双击前的斜体）默认不进入 MRU 列表，但某些操作（如 Ctrl+Click 大纲项）会把它临时塞进去，干扰排序
- 拖拽调整过标签顺序、或用过
Ctrl+1～Ctrl+9，都会重排 MRU，导致历史顺序和视觉顺序彻底脱钩 - 多行下标签更密集，误点相邻 tab 的概率反而升高；悬停提示可能被截断（如
/normalize-utf8.ts），无法确认目标文件
想严格按物理位置左右切？必须手动绑定 workbench.action.previousEditor
VSCode 默认不给 Ctrl+PageUp/Ctrl+PageDown 绑定任何命令，哪怕你开着多行标签栏，这两个键也完全没反应——这不是 bug，是设计如此。
要让它真正实现“左边一个 / 右边一个”，得手动加进 keybindings.json：
[{"key":"ctrl+pageup","command":"workbench.action.previousEditor"},{"key":"ctrl+pagedown","command":"workbench.action.nextEditor"}]
注意几个硬性前提：
- 别用已废弃的
workbench.action.openPreviousEditor，VSCode 1.80+ 会静默忽略 - 这两个命令只作用于当前编辑器组，且要求至少有两个**已固定**（非预览）的标签页；最左/最右时按了也没反馈，不会循环
- macOS 用户不能直接用
Cmd+PageUp（系统不传事件），得改用Cmd+Shift+[或Cmd+Shift+]
Ctrl+1～Ctrl+9 在多行下行为不变，但定位更难
这些快捷键始终对应“第 N 个**已固定**的标签页”，跟行数、是否换行完全无关。问题在于：多行后，你很难一眼判断哪个是第 5 个——它可能在第二行中间，也可能在第一行末尾，全凭打开和拖拽历史决定。
典型踩坑点：
- 第 3 个位置是预览标签（斜体）？
Ctrl+3会直接跳到第 4 个固定标签，而不是停住或报错 - 拖拽过标签页后，编号跟着物理位置变，但你脑子里还记着旧顺序，按
Ctrl+5却切到了意料之外的文件 - 多行 + 长路径名 → 标签文字被截断（如
src/.../string/normalize-utf8.ts→/normalize-utf8.ts），靠名字盲按风险陡增
真正容易被忽略的底层事实：标签页状态比行数重要得多
VSCode 的标签页本质是三层状态叠加：预览态（临时、斜体）、固定态（常驻、正常字体）、编辑器组（分屏容器）。所有快捷键行为都由这三者组合驱动，而不是由“标签栏是否换行”这个纯渲染属性决定。
比如你开了 20 个文件、启用多行显示，但其中 15 个仍是预览态——那 Ctrl+Tab 面板里实际只有 5 个可选，Ctrl+1～Ctrl+9 也只对这 5 个有效。此时换不换行，只是让标签栏“看起来满”，并不改变操作逻辑的复杂度。
