摘要：说白了，这不是空穴来风。你要是愿意翻源码，就能看到几处明显的线索，说明团队在把“标签只能横着排”这件事改成“方向可选”的工程。像 Edge、Vivaldi 早就把标签放在侧边栏当惯了，Chrome 一直是顶上那一排。现在 Chromium 的工程师们正在把底层

Chromium 已经开始在代码里为垂直标签页做准备，相关的基础设施在逐步搭建，迹象并不只是传闻，而是能在源码里找到的实体线索。

说白了，这不是空穴来风。你要是愿意翻源码，就能看到几处明显的线索，说明团队在把“标签只能横着排”这件事改成“方向可选”的工程。像 Edge、Vivaldi 早就把标签放在侧边栏当惯了，Chrome 一直是顶上那一排。现在 Chromium 的工程师们正在把底层架构往能支持竖排的方向改造——留着横排也行，想竖排就切换。

能拿出来看的第一个证据，是问题追踪里的条目，编号是 420041296，标题和垂直标签列表、共享选项有关。再深入看源码，会发现 chrome/common/pref_names.h 里有个偏好键 vertical_tabs.enabled，像布尔值那样存在。还有关于 flag 注册的代码片段出现在 chrome/browser/about_flags.cc 里，说明这类功能可能会通过 chrome://flags 暴露给测试用户。换句话说，社区里不是有人臆测，确实有“留插槽”的痕迹。

再看 UI 层的代码，像 chrome/browser/ui/views/tabs/tab_strip.cc 里，现有的实现里在计算标签的垂直间距时，是基于标签在顶部横排这个前提。很多交互逻辑、事件处理、溢出处理都默认标签是一行摆着的，这种假设分布很广。把这种假设拆掉，不是改两行代码能解决的：布局需要重写，拖拽的行为得重新定义，溢出时的滚动方向要改动，主题渲染和扩展的兼容也得跟上。

从工程角度看，团队首先做的是搭基础，而不是直接给所有人推新 UI。这里面包括方向抽象化，也就是把“横着还是竖着”变成一个可配置的属性；然后是功能标志（feature flag），方便分阶段放开给少部分用户试用；再有遥测埋点，用来观测性能、稳定性和兼容性。只有这些基础到位后，才会把侧栏的具体实现交到用户面前让大家试用和反馈。

细活不少。侧边栏要能调宽度，能收起、能展开，这和现有主题系统要保持一致；拖标签的交互得在竖排下做流畅的表现，拖一堆标签到侧边，或者从侧边拖回顶部，都要顺手；原来的溢出处理从水平滚动改成竖直滚动，或者用折叠式清单，设计上得选一个既直观又不影响性能的方案。扩展兼容是个大问题，很多扩展默认以顶端横排为前提写逻辑，放到侧边后 DOM 或行为假设可能就被打破。要么给扩展一层兼容层，要么靠文档和足够的过渡期让扩展作者改代码，两条路都得花时间。

性能监测不能少。需要盯的指标包括侧栏模式下内存占用是否上升、渲染延迟有没有变化、拖拽时帧率和流畅度、扩展出错率、用户在两个模式间切换的比例等。工程里通常会在 flag 里埋点、在 Canary 或内部构建上做 A/B 测试，根据回收来的数据调整实现。通俗点讲，先在小范围里试水，数据好才敢往大范围放。

对日常用户的好处也挺直观。打开几十个标签的人，顶栏那点儿空间一挤，标题就看不清楚；放到侧边来，标题更容易读全，分组也更容易观察。尤其是超宽显示器，左边栏或右边栏那块空间平常没怎么利用，放标签就很合适。举个例子，我工作时常常把文档、任务页、资料页开一堆，用侧栏把同一主题的标签归一列，眼睛扫一遍就知道哪些是当前任务，这体验不是换个皮那么简单，是工作方式的调整。

不过大家别急着把稳定版当饭香。到目前为止，外面能看到的主要是问题跟踪条目、偏好键、flag 注册的蛛丝马迹，还有媒体拿到的内部变更提到这方向。很多提交还是在内部或私有分支，公开的快照里不一定马上能看到完整的“垂直标签页”实现。照常套路，先在 Canary 或开发者渠道出现，收集遥测和兼容性数据，修一轮又一轮，才会逐步推广到 Beta、最终到 Stable。

如果你是扩展开发者或高级用户，能做的准备也挺明确：关注源码更新、留意 chrome://flags 是否出现相关条目，或者在问题追踪里跟踪编号 420041296 的讨论。扩展作者则可以先思考一下自己的扩展是否依赖标签在顶端的 DOM 或事件模型，评估一下改造成本。对普通用户来说，更多是观察和等候，等团队把体验打磨平稳，再决定要不要切到侧栏模式。

总的来看，这项工作不是临时念头，而是一步步有计划的工程推进。眼下的证据足以支撑“Chromium 正在为垂直标签页做长期准备”这个判断，但具体何时会在正式版出现，还要看遥测、兼容性测试和社区反馈的结果。

来源：爱娃爱健身的灵犀爸