VSCode标签页数量上限由workbench.editor.limit.enabled（必须为true）、workbench.editor.limit.value（数值）和workbench.editor.limit.perEditorGroup（分组计数）共同控制，缺一不可。
VSCode 标签页数量上限由什么控制
VSCode 本身没有提供「最多打开 N 个标签页」的内置设置，workbench.editor.limit.enabled 这个配置项才是关键开关——但它默认是 false，也就是不限制。一旦设为 true，才启用数量限制逻辑。
真正起作用的是配套的两个参数：workbench.editor.limit.value（具体数值）和 workbench.editor.limit.perEditorGroup（是否按编辑器分组单独计数）。不配全这三项，改了也无效。
常见错误现象：settings.json 里只加了 "workbench.editor.limit.value": 10，但没开 limit.enabled，结果完全没反应。
-
workbench.editor.limit.enabled必须设为true -
workbench.editor.limit.value推荐设为12～20：太小（如5）会导致频繁关闭旧标签，影响多文件比对；太大（如50）可能拖慢渲染，尤其在低配机器上 -
workbench.editor.limit.perEditorGroup默认false，设为true后，每个分栏（split view）各自独立计数，适合多栏并行开发场景
如何安全启用标签页数量限制（避免误关重要文件）
启用后，VSCode 会自动关闭「最久未激活」的标签页，而不是按打开顺序或修改状态判断。这意味着：你刚切走写了几行的临时 scratch.ts，可能被立刻顶掉，而一个只读的、三天没点过的 README.md 却留着。
这不是 bug，是设计如此——它只看 last focused time，不区分内容重要性。
- 务必配合使用
workbench.editor.reopenLastSession（默认true），否则重启后被顶掉的文件就真丢了 - 对关键文件，右键标签页 →
Keep Open，这类文件会被豁免限制，图标带锁标识 - 禁用
workbench.editor.enablePreview（设为false）：预览模式下的文件不算「已打开」，容易误判剩余名额，关掉更符合直觉
为什么改了设置没生效？检查这三个地方
VSCode 的编辑器限制逻辑只在「新标签页打开时」触发，不是后台常驻监控。所以改完设置不会立刻关掉已有标签，要等下一次打开第 N+1 个文件才生效。
另外，插件可能绕过限制：比如 GitLens 的「Open File on Left/Right」、或者某些调试器自动打开的 debug.log，它们走的是内部 API，不受 workbench.editor.limit 约束。
- 确认修改的是当前工作区的
settings.json，不是用户级设置——工作区设置优先级更高，但也更容易被忽略 - 检查是否有插件覆盖了行为：临时禁用所有插件，用
Ctrl+Shift+P→Developer: Toggle Developer Tools看 Console 是否报editor limit相关警告 - Mac 用户注意：系统级快捷键
Cmd+T（新建标签）和 VSCode 的Ctrl+Tab（切换）行为不同，前者受限制，后者只是导航，不触发关闭逻辑
性能与兼容性要注意的实际细节
开启限制后，VSCode 每次打开新文件都会做一次 LRU 排序，对几百个已打开标签的极端情况，会有轻微卡顿（约 10–30ms）。不过日常 20 以内基本无感。
这个功能从 VSCode 1.67（2022 年 4 月）才稳定支持，老版本即使写了配置也不会生效。检查方法：运行 code --version，低于 1.67.0 就得升级。
- 远程开发（SSH/Containers）场景下，限制逻辑发生在本地客户端，和远端资源无关，但网络延迟可能导致「关闭旧标签」反馈变慢
- 如果用了
files.hotExit（热退出），被限制关闭的文件仍会保留在恢复列表中，下次启动时可选是否重开——但这不等于自动保存，未保存内容依然会丢 - 终端（Terminal）标签页、调试控制台（Debug Console）不计入限制，它们属于独立面板，和编辑器标签页不在同一计数体系里
真正难处理的是那种「打开一堆日志文件快速扫一眼」的场景：限制会强制你手动 Keep Open 或反复重开，这时候不如暂时关掉限制，而不是硬调低数值。
