底部白边通常与浮动无关，主因是line-height、font-size、HTML换行产生的文本节点或父容器自身的padding/margin；应优先检查Computed面板高度、line-height值及是否存在#text节点。
清除浮动后父容器底部仍有白边，大概率不是浮动问题
清除浮动（比如加 ::after 伪元素或 display: flow-root）只解决父容器高度塌陷，但不会动它原本的盒模型尺寸。底部白边往往来自别的地方：line-height、font-size、HTML 换行产生的文本节点，或者父容器自身的 padding-bottom / margin-bottom。
- 用开发者工具选中父容器，在 Computed 面板里看
height是否已正常撑开 —— 如果是，那白边就和浮动无关 - 检查
line-height值是否异常大（比如继承了2或1.8），哪怕里面全是浮动元素，它仍会撑高行框底部 - 把 HTML 中浮动元素之间的换行删掉：
<div class="float"></div> <div class="float"></div>，空格/换行会被解析为文本节点，参与 IFC 计算 - 临时给父容器加
outline: 1px solid red，看白边是否属于该容器自身（比如padding-bottom: 20px）
为什么 overflow: hidden 清除浮动后底部还有空隙？
overflow: hidden 确实能触发 BFC 解决塌陷，但它不重置任何样式。如果父容器本身有 line-height: 2 或 font-size: 16px，且内部残留文本节点（哪怕只是换行符），依然会生成一个不可见但有高度的行框，撑出底部空隙。
- 这个空隙在 DevTools 里常表现为「父容器高度 = 浮动子元素高度 + 若干像素」，多出来的就是行框底边空间
-
overflow: hidden还可能意外裁剪阴影、下拉菜单、tooltip，别把它当万能开关 - 更干净的做法是：清除浮动的同时，显式设
line-height: 1或font-size: 0（注意子元素要重置font-size） - 若子元素含文字，
font-size: 0不可用；此时应改用display: flex容器，天然绕过 IFC 行框干扰
display: flow-root 为何有时也压不住底部白边？
display: flow-root 能让父容器形成 BFC 并正确包裹浮动子元素，但它不改变父容器自身的排版上下文类型 —— 如果父容器仍是块级格式化上下文（BFC），而内部有未清除的文本节点，那些节点仍按 IFC 规则参与行框计算。
- 常见陷阱：父容器用了
display: flow-root，但 HTML 里浮动元素之间留了空行，导致一个匿名文本节点被渲染，高度由font-size和line-height决定 - 验证方式：在 Elements 面板里把鼠标悬停在父容器上，看是否有「#text」节点夹在浮动子元素之间
- 修复建议：要么压缩 HTML（移除换行），要么给父容器加
font-size: 0+ 给浮动子元素显式设font-size（仅当子元素含文字时） - 如果子元素只有图片，直接上
vertical-align: bottom或display: block更干脆，flow-root在这里纯属冗余
真正该盯住的三个地方，而不是反复调 clear
清除浮动只是手段，不是诊断起点。底部白边持续存在，说明你还没定位到真实来源。优先排查这三项：
立即学习“前端免费学习笔记（深入）”；
-
<p></p>标签作为父容器 —— 它自带margin-bottom: 1em，比浮动问题更常见 - 图片后面跟着换行或空格 —— 在图文混排场景下，这个空格会被渲染，并受父级
line-height放大 - 导出的图片带透明画布或底部留白 —— CSS 无法裁剪内容区，得回设计稿重切资源
浮动布局本身已退出主流布局职责，这些白边问题本质是旧模型与现代排版规则碰撞的副产品。真要一劳永逸，不是把 clear 写得更密，而是确认当前场景是否还非用浮动不可。
