手機版面 overflow 排查筆記：用 DOM Probe 驗證 RWD 問題

手機版面最常見的誤判，是看到截圖右側好像被切掉，就立刻開始改 CSS。實際上，畫面「看起來擠」和頁面真的產生水平 overflow 是兩件事：前者可能只是資訊太密、字距太近；後者則會讓使用者在手機上左右滑動，影響閱讀與品牌品質。

UCAMC 在整理首頁、Blog 列表與文章頁時，我會把手機版面檢查拆成兩層：先用 screenshot 找出可疑區域，再用 DOM Probe 確認是否真的超出 viewport。這樣做可以避免為了修一張視覺截圖，反而把原本正常的排版改壞。

不要只相信截圖，要先確認頁面是否真的變寬

第一個訊號是頁面層級的寬度。若 document.documentElement.scrollWidth 大於 clientWidth，通常代表有元素把頁面撐寬；若兩者相等，截圖上的右側緊繃感可能只是間距、字級或卡片密度問題。

可以用這樣的觀念檢查：

const root = document.documentElement;

const pageWidth = {
  clientWidth: root.clientWidth,
  scrollWidth: root.scrollWidth,
  hasPageOverflow: root.scrollWidth > root.clientWidth,
};

這個數字不會直接告訴你哪裡壞掉，但可以先回答一個關鍵問題：現在要修的是「真正的水平 overflow」，還是「視覺上太擠」。兩種問題的處理方式不同。

找出超出 viewport 的元素，而不是亂改全站 CSS

如果頁面真的變寬，下一步才是找元素。常見兇手包括：

沒有 max-width: 100% 的圖片或 iframe。
一整排不換行的 tag、分類 pill 或 CTA。
表格、程式碼區塊、長網址。
使用 width: 100vw 又加上 padding 的區塊。
絕對定位裝飾元素超出容器。

我會先掃描主要內容裡的元素邊界，而不是直接把 overflow-x: hidden 加到 body。後者雖然能把症狀藏起來，卻可能讓真正需要捲動的內容被截斷。

const viewport = document.documentElement.clientWidth;

const offenders = [...document.querySelectorAll('main *')]
  .map((element) => {
    const rect = element.getBoundingClientRect();
    return {
      tag: element.tagName.toLowerCase(),
      className: element.className,
      left: Math.round(rect.left),
      right: Math.round(rect.right),
      width: Math.round(rect.width),
    };
  })
  .filter((item) => item.right > viewport + 1 || item.left < -1);

找到候選元素後，再回到畫面上確認它是否真的是問題。DOM 數字是線索，不是結論。

程式碼區塊要分清楚：可捲動不一定是破版

技術 Blog 經常有長指令、長網址或 JSON。這類內容如果放在 <pre> 裡，局部水平捲動是合理的；真正要避免的是整個頁面被 code block 撐寬。

判斷方式可以分成兩步：

頁面層級不應該 overflow。
單一 <pre> 可以有自己的水平捲動，但視覺上不能像被切掉。

如果 code block 只是局部可捲動，我通常優先做 editorial fix：把長指令拆行、把 placeholder URL 改成說明文字，或把維護紀錄欄位分段，而不是立刻改全站 prose CSS。

從問題型態決定修法

不同 overflow 原因，應該用不同修法：

問題型態	比較安全的修法
圖片撐寬	`max-width: 100%; height: auto;`
tag / pill 不換行	`flex-wrap: wrap; max-width: 100%;`
CTA 在手機太寬	降低 padding、允許換行、改成整列排列
表格太寬	外層建立可捲動容器
長指令或長 URL	先拆行或改寫內容，再評估 CSS
裝飾元素外溢	限制父層 overflow 或調整定位

這也是為什麼排查時要保留「元素是哪一種內容」的脈絡。不是所有超出邊界的數字都應該用同一段 CSS 解決。

把品牌感納入檢查，而不是只看沒有錯誤

手機版面即使沒有水平 overflow，也可能不像正式品牌網站。例如：首頁 Hero 的 CTA 被太多 pill 延後、文章卡片按鈕太密、中文標題斷行不自然、或最新文章區看起來像一排重複模板。

所以 DOM Probe 應該搭配人工視覺判斷：

主 CTA 是否在手機首屏內容易看到。
卡片標題是否能讀懂，不是每行只剩兩三個字。
分類與標籤是否輔助閱讀，而不是搶走 CTA 層級。
文章頁的封面、表格、code block 是否讓讀者願意繼續讀。

對 UCAMC 這類技術內容品牌來說，排版檢查不是只求沒有 console error，而是要讓讀者覺得這個站有人在維護、有一致的內容品質。

建議的日常巡檢順序

每次新增文章或調整首頁後，我會用這個順序檢查：

先跑 production build，避免開發模式誤判。
檢查 /、/blog、新文章 root-level URL。
用 390px 左右的手機寬度看截圖或瀏覽器畫面。
確認 scrollWidth === clientWidth。
檢查 <pre>、表格、圖片是否有不自然裁切。
如果有問題，先修最小範圍，不把全站 CSS 當萬靈丹。

這套流程讓前端排查更像維護工作，而不是看到哪裡怪就改哪裡。當版面問題可以被測量、被截圖、被記錄，網站長期經營才不會累積成一堆難以追蹤的視覺債。

UCAMC 的實務結論

未來 UCAMC 的文章、首頁與 Blog 列表會持續增加內容。越到後面，越不能只靠「我覺得畫面正常」來判斷品質。比較穩的做法，是把視覺檢查、DOM 數據、route 驗證與 SEO 檢查放在同一個發布流程裡。

手機版面排查的目的不是追求每個元件都一模一樣，而是確保讀者在最常見的裝置上能順利閱讀、點擊與理解內容。只要這件事被穩定執行，技術 Blog 就會從一堆文章慢慢變成可信任的內容產品。

手機版面看起來怪？用 DOM Probe 找出真正 overflow 的前端排查筆記