CSS 布局排查方法：别只靠改到看起来对
同一段 flex 代码，标题短的时候一切正常，标题一长就把右边的按钮挤出容器；同一个弹窗，在列表页浮在最上层，挪到详情页就被卡片盖住，z-index 加到六位数也没用。代码没改，行为却在两个场景里完全不同——这才是 CSS 布局最折磨人的地方。
我早年排查布局也是"试出来"的：改一下 position，试一下 z-index，实在不行给父级来一个 overflow: hidden。页面最后看起来对了，但没人说得清为什么对，下一个需求一改又坏。做电商中后台这几年，页面密度越堆越高，我慢慢发现布局问题几乎都能顺着浏览器的布局规则推出来，靠碰运气只是把问题推给下一次迭代。
先确认盒子到底在哪
排查布局的第一步不是改样式，是看盒子。
打开 DevTools 选中元素，我会先把这几件事看清楚：它自己的实际宽高是多少，margin / padding / border 各占多少，父元素给了它多大空间，它是不是被某一层 overflow 裁掉了，有没有 transform 或定位改了它的参照系。
很多"不居中"其实是父容器宽度不对；很多"没显示"其实是高度塌成了 0；很多"点不到"其实是被一个透明元素盖在上面。这些现象表面各不相同，回到盒模型就一目了然。
盒模型里最该先确认的是 box-sizing。默认的 content-box 下，width 只算内容区，padding 和 border 是额外往外撑的——你给一个元素 width: 200px 再加 padding: 20px，它实际占 240px，"怎么算好的宽度总是溢出"多半是这个。现在项目基本都会全局设 box-sizing: border-box，让 width 把 padding 和 border 包进去，尺寸所见即所得：
1*, 2*::before, 3*::after { 4 box-sizing: border-box; 5}
但排查老代码时不能想当然——先在 DevTools 里确认这个元素到底是哪种 box-sizing，不然你按 border-box 心算，它却是 content-box，怎么都对不上。
我排查时经常临时加一句：
1* { 2 outline: 1px solid rgba(255, 0, 0, 0.2); 3}
outline 不占布局空间，比 border 更适合临时描边——border 会改变盒子尺寸，让你在排查一个布局问题时又引入一个新的布局偏移，outline 画在盒子外沿、完全不参与布局计算，加上它盒子边界立刻显形，还不干扰原有排布。看完就删，别留在代码里。给不同层级配不同颜色（比如祖先红、父级绿、自己蓝），嵌套关系也能一眼看清。
Chrome DevTools 里还有两个我几乎每天用的开关：元素面板旁边勾上 Grid / Flex 的 badge，浏览器会把轨道线、间距、对齐方向直接画在页面上；Layout 面板里能列出页面所有 grid 容器，一键叠加参考线。不用自己脑补轨道落在哪，眼睛看得到的信息不要靠想象。
别忘了普通文档流本身也有脾气
在急着上 flex 和 grid 之前，我想先补一段最容易被跳过的东西——normal flow。很多布局怪象其实还没轮到弹性布局登场，就已经在普通流里出了岔子。
最典型的是外边距合并（margin collapsing）。两个上下相邻的块级元素，它们之间的垂直 margin 不会相加，而是取较大的那个；父元素和第一个子元素之间的 margin，还会"穿透"到父元素身上，看起来像是父元素自己往下掉了一截。很多人调间距时越加越乱，就是没意识到自己在跟合并规则较劲。
1.parent { 2 /* 子元素的 margin-top 穿透上来，父元素整体下移 */ 3} 4 5.parent > .child { 6 margin-top: 24px; 7}
想切断这种穿透，给父元素加一层 padding、border，或者干脆把父元素变成 BFC（比如 overflow: hidden、display: flow-root），合并就不再发生。display: flow-root 是专门为"我只想开一个干净 BFC、又不想引入 overflow 副作用"准备的，比老式的 overflow: hidden clearfix 干净，遇到浮动没被包住、margin 乱穿透，我现在优先用它。
顺带提一句，如果整块布局都用 flex 或 grid 排，其实就没有外边距合并这回事了——合并只发生在普通流的块级元素之间，flex/grid 的子项之间用的是 gap，压根不合并。这也是我倾向于用 gap 而不是 margin 控间距的一个隐性理由：省掉了一整类合并带来的意外。
理解这层的意义在于：如果一个元素位置不对，先分清它到底是在普通流里被 margin 规则挪走了，还是真的进了 flex / grid 才出的问题。搞错层级，后面怎么试都是白费。
flex 溢出，先怀疑那个 min-width: auto
Flex 布局里最高频的问题就是元素被挤压或者撑破容器。
1.row { 2 display: flex; 3} 4 5.title { 6 flex: 1; 7}
标题一长就把右侧按钮顶出去，很多人第一反应是加 overflow: hidden，但通常不够。关键在于 flex item 的 min-width 默认是 auto——它不肯收缩到比自身内容的最小宽度更窄。一段不换行的长文本，它的最小内容宽度就是整段文本的宽度，于是它宁可撑破容器也不缩。
要真正让它收缩，得把这个隐含的下限打开：
1.title { 2 min-width: 0; 3 overflow: hidden; 4 text-overflow: ellipsis; 5 white-space: nowrap; 6}
min-width: 0 是 flex 溢出问题里出现频率最高的答案。它告诉这个 item：可以缩得比内容还窄。理解了这一层，就不会再对着 overflow 反复试。
跟它成对出现的还有 flex-shrink 和 flex-basis。flex: 1 其实是 flex: 1 1 0% 的简写，三个值分别是放大比例、收缩比例、基准尺寸。收缩比例默认是 1，也就是所有 item 都愿意在空间不够时按比例缩;偏偏有人会写 flex-shrink: 0 想让某个元素"不被压扁"，结果它宁死不缩，把别的元素挤没了。所以看到某个 flex 元素死活不肯让位，先查它是不是被写了 flex-shrink: 0。理解这三个值分别管什么，比背"flex: 1 是干嘛的"有用得多。
另一个常被搞混的是主轴和交叉轴。justify-content 管主轴，align-items 管交叉轴，而主轴方向由 flex-direction 决定，不一定永远是水平的。一旦写了 flex-direction: column，这两个属性的作用方向立刻对调，很多"对齐怎么不生效"就是栽在这里。判断方法很简单：先看 flex-direction，确定主轴指哪，再看 justify-content 沿这个方向排、align-items 沿垂直于它的方向排。方向搞对了，属性自然就对了。
顺带一提，flex 容器的 gap 属性从 Safari 14.1 起就能放心用了，中后台里那种按钮组、标签行，用 gap 排间距比给每个子元素写 margin-right 再清最后一个干净得多。过去那种 .item + .item { margin-left: 8px } 的相邻选择器写法虽然也能用，但换行、倒序、条件渲染时容易漏，gap 是容器统一管间距，稳得多。
grid 更适合二维，但一样会溢出
如果一块区域同时关心行和列，Grid 往往比 Flex 讲得清楚。
一个自适应卡片列表：
1.cards { 2 display: grid; 3 grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); 4 gap: 16px; 5}
这比手写百分比、margin 再配一堆媒体查询清爽太多，容器一宽自动多排一列，一窄自动少排一列。
但别以为 1fr 就不会溢出。fr 分配的是剩余空间，轨道里塞进一段不换行的长内容时，它照样能把轨道撑破。解法和 flex 是同一个思路：
1grid-template-columns: minmax(0, 1fr) 320px;
minmax(0, 1fr) 把轨道的最小尺寸从默认的 auto 压到 0，允许它收缩,和 flex 里的 min-width: 0 是一回事。两个不同的布局模型，撞的是同一堵墙，记住这个共性能省很多排查时间。
Grid 还有一个我今年才用顺手的能力——grid-template-areas。中后台那种头部、侧栏、主区、页脚的经典框架，用命名区域画出来，改布局时几乎不用动 HTML 结构，响应式下换一套 areas 就能整块重排，比一堆 grid-column: 1 / 3 直观。
grid 里还有一个和 min-width: 0 同源、但更隐蔽的坑：内部滚动。假设主区是一个 grid 单元，里面塞了一个需要独立滚动的长列表，你给列表加了 overflow-y: auto，却发现它不滚，反而把整个页面撑高了。原因还是那个默认的最小尺寸——grid 项目的 min-height 默认也是 auto，它不肯比内容矮，于是列表把单元格顶起来，根本没机会触发滚动。补一句就好：
1.main-cell { 2 min-height: 0; 3 overflow: hidden; /* 或者交给内部列表自己 overflow-y: auto */ 4}
min-width: 0 管横向、min-height: 0 管纵向，flex 和 grid 都吃这一套。撑破容器、内部不滚动、fr 轨道溢出，追到底都是这一个默认值在作怪。把这个共性记牢，等于一次性拿下一大类布局问题。
绝对定位到底相对谁，先搞清楚包含块
position: absolute 的元素"跑偏"了、贴到了意料之外的角落，几乎都是因为对包含块（containing block）的理解出了偏差。绝对定位不是相对页面，也不是相对最近的父元素，而是相对最近的一个"已定位祖先"——也就是设了 position 为 relative、absolute、fixed 或 sticky 的祖先。一个都找不到，就退回到初始包含块，也就是视口。
1.panel { 2 position: relative; /* 给子元素当参照系 */ 3} 4 5.panel .close-btn { 6 position: absolute; 7 top: 8px; 8 right: 8px; 9}
很多"绝对定位的图标飞到页面右上角去了"，就是因为忘了给它想贴的那个容器加 position: relative。它于是一路往上找不到定位祖先，直接贴到视口去了。排查时的动作很固定：选中飞掉的元素，沿 DOM 往上找第一个带 position 的祖先，确认它是不是你以为的那个。
transform、filter、perspective 这些属性还会把元素变成 position: fixed 子元素的包含块——这就跟前面 z-index 那节的坑接上了：父级一个 transform，里面 fixed 的遮罩层就不再相对视口，而是被这个父级框住。定位和层叠这两套规则，很多时候是同一个 transform 同时在搅局。
z-index 不是越大越赢
弹窗、下拉、tooltip 被遮住时，很多人直接甩一个 z-index: 999999。但 z-index 只在同一个层叠上下文里比大小——如果你的元素所在的上下文整体就比对手低，里面的数字再大也翻不了身。
会创建新层叠上下文的常见属性有不少：定位元素配上 z-index、opacity 小于 1、transform、filter、isolation: isolate、position: fixed / sticky，还有 will-change、mix-blend-mode 等。这里最阴的是 transform：父级只要有 transform，里面的 position: fixed 子元素就不再相对视口固定，而是相对这个父级定位，很多"固定定位怎么跟着滚"的诡异现象就是它。
所以排查层级问题，正确动作是从出问题的元素往上找，看它到底落在哪个层叠上下文里，而不是盯着它自己那个 z-index 死磕。DevTools 的 Layers 面板能把合成层画出来，配合这个思路很快能定位是哪一层把人罩住了。
组件库里我更倾向统一层级 token，把语义和数值绑定：
1--z-dropdown: 1000; 2--z-modal: 1100; 3--z-toast: 1200;
别让每个业务页面自己发明数字，那是层级战争的源头。真要隔离某块区域的层级影响，isolation: isolate 能主动开一个干净的层叠上下文，把内部的 z-index 关在里面，不去污染外面。
顺带说个组件库里的现实取舍：弹窗、下拉这类浮层，我们后来干脆用 Portal（React 里是 createPortal）把它们渲染到 document.body 底下，彻底绕开父级那一堆 transform、overflow、层叠上下文的干扰。代价是浮层的定位得自己算、跟着触发元素滚动时要手动更新位置，但换来的是"浮层永远盖在最上面、永远不被祖先裁剪"这个确定性。在业务复杂的中后台里，这笔交易通常划算。
overflow: hidden 是刀，不是胶水
overflow: hidden 经常被拿来"修一下"，它确实能裁掉多余内容，但副作用一串：里面的下拉菜单被切掉、position: sticky 直接失效、盒子的 box-shadow 被削平、无意中造出一个新的滚动容器、焦点轮廓看不见影响可访问性。
判断标准很简单：如果是为了圆角裁一下图片，用在那个局部容器上没问题；如果是拿它去盖布局错误，最好先揪出到底是谁撑破了宽度。
横向溢出是重灾区。与其上来给 body 加 overflow-x: hidden 把滚动条藏掉，我更愿意在 DevTools 里找出那个超过视口宽度的元素——往往就是某个写死宽度的表格、一段没设 min-width: 0 的 flex 文本，或者一张没限制 max-width 的图。给 body 加 overflow-x: hidden 只是把问题藏起来，元素还在那里超出，只是你看不见滚动条了而已。
找那个"元凶"元素有个偷懒但好用的办法，在控制台里跑一段脚本，把所有比视口宽的元素描出来：
1document.querySelectorAll('*').forEach(function (el) { 2 if (el.offsetWidth > document.documentElement.clientWidth) { 3 el.style.outline = '2px solid red' 4 console.log(el) 5 } 6})
红框一亮，谁撑破的一目了然。比手动一层层展开 DOM 快得多。
overflow: hidden 还有个连带坑值得单独记：它会悄悄干掉 position: sticky。sticky 元素要生效，得能在它最近的那个滚动容器里"粘住"；一旦某个祖先因为 overflow: hidden 变成了滚动容器，sticky 的参照系就被这个祖先截断了，粘不到你以为的那个位置。遇到"sticky 怎么不吸顶"，第一反应就该往上找哪个祖先带了 overflow。
响应式一定要拿极端内容去测
响应式布局不能只用设计稿里那份理想文案验收，也别只在自己那台高分屏上点几下就过。真正会把布局搞爆的是这些：一个超长的英文单词或 URL、一条塞满的中文标题、空数据、图片加载失败留下的裂图、浏览器缩放到 200%、窄到 320px 的老手机、系统里放大的字号。这些都不是刁难，是线上真实会出现的输入。
很多布局在正常文案下都好好的，一换长文本就爆开。做电商中后台这几年，我印象最深的一类线上问题就是它：设计稿里商品名永远是"经典款白 T 恤"这种四五个字，运营真上架时甩来一个三十字带括号带规格的标题，卡片当场变形。所以我现在自测时会专门存一份"脏数据"——超长标题、空描述、异常价格、缺图，一键灌进列表看布局扛不扛得住。
CSS 要写成能容纳内容变化，而不是假设内容永远听话。我常备两句保护：
1.text { 2 overflow-wrap: anywhere; 3} 4 5.media { 6 max-width: 100%; 7 height: auto; 8}
今年我还在几个内部页面上试了 text-wrap: balance（Chrome 114 起支持）。它能让多行标题的每行长度更均衡，不至于最后一行孤零零挂一个词。效果确实好，但目前只有新版 Chrome 认，其他浏览器直接忽略，所以我只把它当渐进增强用，不依赖它兜底,主要靠上面那两句稳住布局。
组件级响应式，媒体查询未必够用
还有一个我最近在评估的方向——容器查询（Container Queries）。它从去年 Chrome 105 起落地，到今年浏览器面基本铺开了，可以在内部项目里认真试。
媒体查询判断的是视口宽度，但中后台里有大量组件是"同一个卡片，在宽侧栏里横排、在窄弹窗里竖排"。视口是同一个，组件所处的容器却宽窄不一，媒体查询这时候就使不上劲。容器查询让样式跟着父容器的尺寸走：
1.card-wrap { 2 container-type: inline-size; 3} 4 5@container (min-width: 400px) { 6 .card { 7 display: grid; 8 grid-template-columns: 120px 1fr; 9 } 10}
一个真正可复用的卡片组件，不该关心自己被放进了多宽的页面，只该关心它眼前的容器有多大。这个思路对组件库很对味。不过它毕竟还很新，我目前只在新做的内部工具上用，对外的核心页面还是媒体查询兜底,新能力先在低风险场景练手，是我这几年养成的习惯。
实在定位不到时，二分法比瞎猜快
有时候现象太诡异，一时想不通归到哪条规则，我会退回到最笨但最可靠的办法——二分。在 DevTools 里把可疑区域的一半元素临时 display: none，看问题还在不在。在，说明元凶在剩下这半；不在，就在被隐藏那半。几次对折下来，很快能把范围收缩到具体某个元素，再回头看它身上叠了哪些属性。
这套办法对"到底谁撑破了宽度""到底哪一层开了 overflow"特别管用。布局问题往往是好几个属性叠加的结果，靠脑子一次性推演容易漏；二分不需要你事先想通原理，只需要能观察现象，反而稳。定位到具体元素之后，再用前面那些机制去解释它为什么这样表现，思路就顺了。
要强调的是，二分是定位手段，不是解决方案。找到元素只是第一步，最终还得回到"为什么"上——是哪条规则让它这样，改哪个属性能从机制上解决，而不是随手加个 overflow: hidden 把现象压下去。二分帮你快速缩小范围，理解规则帮你真正修好它，两者配合才完整。
我现在的排查顺序
遇到布局问题，我基本按这个顺序走，一步比一步深入：先在 DevTools 里看盒模型和父容器给了多少空间；再确认当前是哪种布局模式，normal flow、flex、grid 还是定位；接着查有没有 min-width / min-height 挡住了收缩；然后看 overflow 和有没有意外多出来的滚动容器；层级问题从元素往父级找层叠上下文，而不是盲加 z-index；再拿极端内容压一遍响应式；最后才考虑要不要动 HTML 结构。
按这个顺序走下来，前面那两个诡异现象都有了答案：flex 里的按钮被顶出去，是标题那个 item 的 min-width: auto 在作祟，补一句 min-width: 0 就收住了；弹窗在详情页被盖住，是外层卡片有 transform 开了新的层叠上下文，把弹窗关在了里面，把弹窗挂到 body 层级或者给它自己 isolation 就解决了。
这两个案例的共同点是：现象层看起来毫无关联，一个是 flex 收缩、一个是层叠上下文，但只要落到具体机制上，答案都是唯一的，不需要靠"多试几次"去撞。
CSS 不是玄学，它只是规则多、而且规则会互相叠加。按布局模型一层层排查，比对着属性反复试稳得多——重要的不是背下每条规则，而是遇到问题时知道该去查哪一层：是普通流、是 flex/grid 的收缩、是定位的包含块，还是层叠上下文。层级找对了，规则自己会给你答案。