VS Code1.134终于学会了Jetbrains这个丝滑动作

按住 Alt 键再点×，所有其他标签页瞬间消失——这个功能是怎么被“逼”出来的？

如果你用过 JetBrains 家的 IDE（比如 IntelliJ IDEA），你可能已经条件反射地按住 Alt 键去点标签页的 × 了——因为你知道，这么一点，除了当前这个标签页，其他的统统关闭。

如果你没用过，你可能在想：“这不就是个快捷键吗，有啥好大惊小怪的？”

VS Code 的工程师们一开始也是这么想的。直到他们开始做这个功能，才发现事情远没有想象中那么简单。

这个故事的开头：用户想要一个“顺手”的功能

事情要从一个用户反馈说起。有人提了个 Issue 说：“能不能像 JetBrains 那样，Alt+点击关闭按钮，把其他标签页都关了？我每天都要手动一个个点×，太费手指了。”

VS Code 团队一看，觉得挺合理。实现起来应该也不难——监听 Alt 键，然后关闭其他标签页，完事。

但真正开始做之后，他们才发现自己打开了一个“潘多拉的魔盒”。

第一个坑：UI 反馈 — 用户不知道自己在做什么

如果只是加一个 Alt+点击的隐藏快捷键，问题很大：用户可能不小心按到 Alt 然后点了关闭，所有标签页突然消失，然后一脸懵逼：“我刚才做了什么？”

所以必须要有视觉反馈——当用户按住 Alt 时，关闭图标要变成一个不同的图标（比如一个“关闭所有其他”的样式），让用户清楚地知道：“哦，我按了 Alt，现在点击会触发特殊操作。”

这还不够，还要加 tooltip 提示：“关闭其他标签页 (Alt+Click)”——不然用户根本不知道这个功能的存在。 在vscode是叫Close others

第二个坑：固定标签页（Sticky Tabs）

VS Code 有“固定标签页”（Sticky Tabs）的功能，这些标签页是“钉住”的，用户希望它们一直保留。Alt+点击关闭其他标签页时，不应该把固定标签页也关了——否则用户会暴怒。

所以代码里必须过滤掉固定标签页，只关闭非固定的。

第三个坑：匹配逻辑（matches()）的陷阱

这个是最大的坑。

VS Code 里有些特殊的编辑器标签页（比如 Welcome 页面、Walkthrough 教程），它们重写了 matches() 方法，只要类型相同，就认为它们“匹配”——这本来是为了实现“单例”效果（比如 Welcome 页面只能有一个）。

问题是，如果同时有两个这样的“单例”标签页被打开（虽然理论上不应该，但用户总有办法搞出各种状况），Alt+点击关闭其他时，VS Code 可能会把本来不该关的那个也关上，或者把当前这个错误地当成另一个而关掉。

解决方案是：不用 matches() 来判断是否“相同”，而是直接用引用对比（reference identity）——也就是“这个标签页是不是就是当前这个，而不是跟它长得像的另一个”。

所以，为什么要有这个功能？

从用户角度看，这个功能很直观：按住 Alt 点 ×，其他标签页全关掉——省时省力，手指少受罪。

从团队角度看，这个功能的核心价值在于提升标签页管理效率。对于经常打开大量标签页的用户来说，这比手动逐个关闭要快得多。

但真正让人印象深刻的，不是这个功能本身有多“大”，而是 VS Code 团队在处理这个“看起来很简单”的功能时，考虑到了：

• 固定标签页不能动
• 视觉反馈要让用户明白当前状态
• matches() 的特殊性不能影响关闭逻辑
• 点击事件的顺序不能被误触发

最后一个有意思的细节

这个功能的图标设计，参考了 JetBrains 的风格——当你按住 Alt 时，关闭图标会变成“关闭其他”的样式。如果你不按 Alt，图标就是普通的 ×，点击就只关当前这一个。

这种“所见即所得”的设计，让这个功能既容易发现，又不容易误触。现在它已经合入主分支，你可以在下一个 VS Code 版本中体验它了——如果你用的是 Insiders 版本，现在已经能用上了。