Boloop 閱讀示意圖（由 AI 生成）：斷點與彈層邊界需服從實際內容寬度。
Boloop 的頁頭在 719px 視口下，把整頁寬度撑到了 818px。語言切換按鈕的右邊緣也落在屏幕之外，而用於展開移動導航的按鈕還沒有出現。
這裏並不需要重新設計網站。真正需要回答的是：導航內容從多寬開始放不下，彈出選單是否遵守了它聲稱的對齊規則，以及修復後原來的主題和鍵盤操作是否還正常。
斷點應服從內容能否放下
原布局直到 650px 才折疊桌面導航，但它在比這個寬度更大的屏幕裏已經裝不下所有內容。719px 這個樣本，恰好落在「桌面導航已不適用、折疊規則卻未啟動」的區間。
這次將共享導航的折疊範圍調整到 1050px 及以下，超過這個寬度再顯示完整導航。1050px 來自 Boloop 當前頁頭的內容與布局，並不是適用於所有網站的固定平板斷點。
折疊也不等於刪掉操作。Home、搜索、語言切換、主題切換和鍵盤訪問需要保留；其他針對小屏正文的 650px 樣式則繼續使用。只修共享頁頭，才能把變更範圍控制在真正發生問題的位置。
關着的正常選單打開後也可能越界
調整導航之後，語言彈層又暴露出另一個問題。組件實際渲染的是 select-menu-end，但 CSS 卻在匹配 select-menu-align-end。看起來存在「靠右對齊」的樣式，瀏覽器實際使用的節點卻匹配不到它。
在修復前的觀察裏，390px 視口下彈層右邊緣達到 411px，719px 視口下達到 722px。導航容器已經不溢出，並不能替彈出層證明邊界正確。
舊回歸只檢查樣式文件裏是否存在某段字符串，因此也能通過。修正後，檢查對象改成實際渲染的列表框與真正匹配它的選擇器；再打開頁面，量彈層的實際邊界。
這是一個很小卻值得記住的區別：測試裏有 CSS，不代表頁面上有節點在使用它。
默認深色也要照顧已經選過淺色的人
同一輪調整中，Boloop 明確了首次訪問默認深色，同時保留讀者已保存的淺色或深色選擇。
這要求 HTML 頭部的主題啟動邏輯與 React 初始化一致。若它們各用一套默認值，頁面可能先顯示一個主題，載入後又切到另一個；若過早把默認值寫回存儲，還可能覆蓋已有的淺色偏好。
這次讓服務端與客戶端初始標記一致，在初始化準備好後再讀取、持久化偏好。瀏覽器存儲被拒絕時，主題按鈕仍可操作。檢驗默認值時也要使用一個此前沒有保存偏好的新來源；在一個已經選過淺色的瀏覽器裏打開頁面，继续顯示淺色恰好是正確行為。
驗收不只縮到手機寬度看一眼
本地檢查覆蓋英文、簡體中文、繁體中文，首頁、文章目錄與原創指南，以及 390、719、1024、1440px 下的明暗主題，共 72 組布局組合。隨後還檢查斷點附近的寬度，確認 1050px 折疊、1051px 展開，並檢查更窄的入口。
實際操作包括展開導航、跳到文章目錄、用 Escape 關閉選單、用鍵盤打開語言列表、切換語言，並確認主題與焦點恢復。可見頁頭控件還檢查了至少 44×44px 的目標尺寸。只看靜態截圖，會漏掉其中大部分狀態。
獲准發佈後，正式站又執行了三種語言、佈局、彈層和主題持久化檢查。2026 年 10 月 21 日這次發佈的 918 項發佈測試通過；線上檢查沒有觀察到頁頭越界或瀏覽器控制台錯誤。它覆蓋的是這些頁面家族的共享頁頭，不等於每個頁面、每台真機都已測試。
頁面裏其他擠壓問題也要量實際尺寸
此前文章目錄也出現過類似的「看起來像響應式問題」的故障：統計欄設置了 flex-basis: 100%，卡片卻是不換行的橫向 flex，最終把正文容器壓到了 0px。
那次修復將文字型文章卡片改回正常塊流，讓統計信息排在正文之後。它不需要刪除統計，也不需要給標題寫一串更小的字號。
這兩次經歷讓我在改樣式前先量三件事：視口多寬，容器實際多寬，哪一個子元素首先越界。定位到負責分配空間的規則後，修復通常比重新排一遍整頁更明確，也更容易保護已有的動畫、文字選擇和內容層級。