I can't run your page, so everything below is a hypothesis. Each one comes with a check that will confirm or rule it out. Start at 375px, then test 320, 414, 768, 1024 and 1280, and 200% zoom at desktop width.
First, find the widest element. Run the overflow-finder snippet from the skill in the console at 375px. Skip anything inside the table wrapper. The URL card or the table will probably be at the top of the list.
1. Card with a long URL in a flex row (sideways scroll at 375px)
- Cause: a flex item has an automatic
min-width, so it can't shrink below its content. An unbroken URL has no break opportunity, so the card keeps the URL's full width and pushes the row past the viewport. - Fix:
If the row should stack on phones, add.card { min-width: 0; } /* let the flex item shrink */ .card .url { overflow-wrap: anywhere; } /* allow breaks in the URL */flex-wrap: wrapor switch toflex-direction: columnbelow your breakpoint. - Verify: at 375 and 320, the card's
getBoundingClientRect().rightshould be no more than the viewport width, and the URL should wrap inside the card. Test with the longest real URL you have. Removemin-width: 0once to confirm the overflow comes back. That proves this was the cause.
2. Table with 8 columns
- Cause: tables don't shrink below their content width, so 8 columns exceed 375px.
- Fix: scroll the table inside its own container, not the page.
<div class="table-scroll"><table>…</table></div>
If the table is read often on phones, restack each row into a card below about 600px. Don't hide columns. If the wrapper sits inside a flex row, it may also need.table-scroll { overflow-x: auto; max-width: 100%; }min-width: 0. - Verify: the page has no horizontal scrollbar at 375, and only the table area scrolls sideways. Check that every column can be reached and that the wrapper can be scrolled with the keyboard. Add
tabindex="0"to the wrapper if it can't. At 1280 the table should look unchanged.
3. Hero with height: 100vh too tall on phones
- Cause:
100vhis the largest viewport height, measured with the browser bars retracted. While the address bar is showing, the hero is taller than the visible area. - Fix:
Use.hero { min-height: 100vh; /* fallback */ min-height: 100svh; /* or 100dvh if you want it to follow the bars */ }min-heightinstead ofheightso tall content isn't clipped.svhalways fits with the bars showing.dvhresizes as the bars move, which can cause jank. Also check for100vwanywhere on the hero. It can cause sideways overflow of its own. - Verify: this needs a real phone, because emulation doesn't reproduce the browser bars reliably. Load the page with the address bar visible and confirm the hero fits without cutting off its content. Then scroll and confirm nothing jumps.
4. Sticky sidebar doesn't stick on desktop
- Cause: the parent has
overflow-x: hidden. Anyoverflowvalue other thanvisiblemakes that element the sticky element's scroll container. Because it never scrolls vertically, the sidebar has nothing to stick against. Less likely, but worth checking: the sidebar has notopvalue, or its parent isn't taller than the sidebar. - Fix: remove
overflow-x: hiddenfrom that parent, or move it somewhere that isn't an ancestor of the sidebar. If it was there to hide the overflow from bug 1 or 2, fixing those removes the need for it. If you must clip,overflow-x: clipdoesn't create a scroll container, so sticky keeps working..sidebar { position: sticky; top: 1rem; align-self: flex-start; }align-self: flex-startmatters if the parent is a flex or grid container. A stretched sidebar is as tall as its parent and has no room to stick. - Verify: at 1280, scroll the page and confirm the sidebar stays pinned. In DevTools, walk up the ancestor chain and check that none has an
overflowother thanvisible. Then check 375 again, since removing the clip could expose any overflow that remains.
Order of work
Fix 1 and 2 first and re-run the finder. Then fix 4, which removes the clip that was hiding the problem. Without both, you'd be hiding the overflow while breaking sticky. Do 3 last, on a real device.
I haven't tested any of this. If you can paste the computed styles for the card, the table wrapper and the sidebar's ancestors (not your code), I can narrow the causes down further.
Real run in an isolated folder with only this skill installed. Only the Skill and Read tools were enabled, so no command was run and no file was written. The scenario is fictional and the model had no access to the code. Everything in the answer is a hypothesis with a check to confirm it.
它做什麼
一套除錯在某些螢幕寬度下才出問題的版面的方法。它堅持先在一個明確的寬度下重現問題,再用一段主控台程式碼列出比視窗更寬的元素,找到確切溢出的那個元素,然後才去改 CSS。一張「症狀—原因」對照表涵蓋了常見的元凶:固定寬度與 100vw(它包含捲軸寬度)、有自動最小尺寸的 flex 與 grid 子項(min-width: 0)、很長的不間斷字串、圖片、表格、被祖先 overflow 或過矮的父元素擋住的 position: sticky、被困在堆疊內容中的 z-index、被裁掉的下拉選單、手機上的 100vh(dvh 與 svh)、安全區(viewport-fit=cover 與 env())、grid、viewport meta 以及版面位移。
還涵蓋
在內容出問題的地方選斷點、行動優先的寫法、相對單位、容器查詢、觸控目標、200% 文字縮放與 320 像素重排,以及要測試的寬度與條件清單。它還提醒不要靠在 html 或 body 上隱藏溢出來「修復」。
適合什麼場景
手機版面 bug、「只在某個寬度才出問題」,以及會橫向捲動的頁面。
低風險:純指令檔,沒有腳本,不連網、不寫檔。其中有一小段讓你貼到瀏覽器主控台的程式碼,只讀取元素位置,不改變頁面。它看不到你的頁面,所以給出的都是附驗證方法的假設,並說明沒有測試的部分;模擬器無法可靠還原瀏覽器工具列與安全區,涉及這些時請用實機測試。較新的 CSS 特性(容器查詢、`dvh`)需要對照你的瀏覽器核對支援情況。AIBars 原創(MIT)。已用一個虛構頁面試用過一次。