如果你曾經試圖在使用寬螢幕顯示器的瀏覽器中管理 30-40 個開啟的分頁，你可能就能理解將分頁列轉到側邊的吸引力。這已經是 Microsoft Edge、Vivaldi 等瀏覽器多年的標準配備。同時，基於 Chromium 的瀏覽器（包括 Google Chrome）一直使用水平分頁列。直到現在。

Chromium 中最近的提交活動表明，開發團隊正在為垂直分頁奠定重要的基礎：功能標誌、偏好設定鍵、佈局分支 —— 所有在為使用者啟用功能之前必須到位的基础設施。其中一些隱藏在內部問題和早期的 CL 中，但公開的指標清楚地指向這個方向。例如，Chromium 問題追蹤器上的問題 #420041296 的標題是新增分享選項和垂直分頁列表顯示。

為什麼花了這麼長時間

垂直分頁沒有更早出現的原因歸結於架構。Chromium 的 UI 堆疊是圍繞瀏覽器視窗頂部的水平分頁列的假設而構建的。佈局程式碼、事件處理（分頁的拖放、溢位行為）、擴充功能 API、主題 —— 所有這些都假設視窗寬度上只有一列分頁。

要翻轉這一點 —— 允許分頁位於側邊欄中、垂直堆疊、以不同的方式滾動、以不同的方式調整大小 —— 意味著重構許多元件。這也意味著要保持與舊版行為（擴充功能、視窗、設定檔）的相容性，並引入可切換的路徑（以便水平模式仍然有效）。因此，團隊似乎沒有交付一個零碎的版本，而是首先構建基礎設施：標誌、方向抽象、指標。

程式碼顯示了什麼

幾個可觀察到的變化暗示了方向。首先：一個偏好設定鍵。在 Chromium 原始碼中，chrome/common/pref_names.h 中有一個常數，保留了一個類似布林值的 vertical_tabs.enabled 偏好設定。僅此一點就表明預期會有垂直分頁的使用者狀態。

第二：標誌註冊。在 chrome/browser/about_flags.cc 中，你可以看到如何列舉標誌以透過 chrome://flags 顯示。雖然我找到的公開快照中沒有立即看到確切的垂直分頁條目，但模式是明確無誤的。

第三：佈局程式碼顯示了分頁列目前如何使用水平假設。例如，在 chrome/browser/ui/views/tabs/tab_strip.cc 中，有以下程式碼片段：

void TabStrip::UpdateNewTabButtonBorder() {
  const int extra_vertical_space = GetLayoutConstant(TAB_HEIGHT) -
                                   GetLayoutConstant(TABSTRIP_TOOLBAR_OVERLAP) -
                                   NewTabButton::kButtonSize.height();
  constexpr int kHorizontalInset = 8;
  new_tab_button_->SetBorder(
      views::CreateEmptyBorder(gfx::Insets(
          extra_vertical_space / 2, kHorizontalInset, 0, kHorizontalInset)));
}

在這裡，程式碼明確地計算垂直間距，假設分頁列是水平的 —— 說明了有多少 UI 邏輯需要為垂直佈局進行調整。

將這些放在一起，一個關鍵的內部變更可能看起來像這樣：

// In tab_strip_model.h or equivalent:
enum class TabStripOrientation {
  kHorizontal,
  kVertical,
};

// In the constructor:
TabStripModel::TabStripModel(Profile* profile, Browser* browser)
   : orientation_(TabStripOrientation::kHorizontal),
     browser_(browser) {
  if (base::FeatureList::IsEnabled(features::kVerticalTabs) ||
      profile->GetPrefs()->GetBoolean(prefs::kVerticalTabsEnabled)) {
    orientation_ = TabStripOrientation::kVertical;
  }
}

在 UI 佈局的其他地方：

if (orientation_ == TabStripOrientation::kVertical) {
  // use SidePanelTabStripView for vertical layout
  view_ = std::make_unique(...);
} else {
  // existing HorizontalTabStripView
  view_ = std::make_unique(...);
}

雖然我無法在這篇文章中指出公開的提交雜湊（這些 CL ID 是內部/私有的），但問題追蹤器 (#420041296) 和媒體報導提供了足夠的確認，表明這些變更正在進行中。

這實現了什麼 —— 以及仍然需要做什麼

透過方向抽象和功能標誌，Chromium 可以開始支援兩種工作流程：為大多數使用者保留經典的水平分頁列，並允許高階使用者切換到垂直側邊欄佈局。該側邊欄將提供堆疊的分頁（具有完整標題可見）、更輕鬆的分頁分組、改進的許多開啟分頁的掃描 —— 尤其是在超寬螢幕顯示器上。

但前方的道路仍然有工作要做。UI 需要支援調整側邊欄大小、摺疊/展開行為、與水平 UI 同步的主題、垂直堆疊中的拖放、溢位處理（垂直而不是水平滾動）以及擴充功能 API 相容性（許多擴充功能假設分頁位於頂行）。遙測必須收集有關使用情況和效能的資料，以確保該功能可以廣泛推出而不會引入回歸。

目前尚不清楚使用者介面切換開關何時會出現在穩定版本中。在這個階段，該標誌可能僅在早期版本（例如，Chromium Canary）或內部版本中，並且尚未公佈公開發布日期。

為什麼這很重要

對於開發人員、瀏覽器高階使用者以及保持數十個分頁開啟的人來說，這是一個受歡迎的轉變。垂直分頁佈局減少了認知負荷：你可以閱讀完整標題、以視覺方式對分頁進行分組，並使用寬螢幕上原本未使用的側面空間。從工程的角度來看，這很有趣，因為它反映了一個基本的 UI 架構變更：曾經僅限水平的模型現在正在轉變為與方向無關的佈局。這在像 Chromium 這樣龐大且跨平台的程式碼庫中並非易事。

功能標誌和方向邏輯的存在表明 Chromium 團隊正在花時間 —— 構建基礎、收集遙測、為擴充功能相容性做準備 —— 而不是發布一個快速的駭客程式。這表明這不僅僅是一個實驗：它很可能會以有意義的方式提供給使用者。

總之：垂直分頁即將登陸 Chromium。架構基礎正在積極奠定。對於每天耕耘瀏覽器分頁叢林的任何人來說，這都是一個值得為之準備的改變。