根本原因是父容器高度塌陷与后续元素回归文档流，而非遮挡；应通过 display: flow-root 创建BFC使父容器包含浮动子元素，避免overflow:hidden的截断风险。
浮动元素被后续元素覆盖，根本不是“遮挡”问题，而是父容器高度塌陷 + 后续元素回归文档流导致的布局错位。解决重点不在子元素上加 clear，而在让父容器“看见”浮动子元素。
为什么后续元素会覆盖浮动区域？
浮动元素脱离文档流，父容器计算高度时直接忽略它们，结果高度变成 0 或远小于实际内容。后续块级元素（比如 <p></p>、<section></section>）就从父容器顶部开始渲染，视觉上“叠”在浮动内容上——其实它只是按标准流正常往下走，而浮动内容“悬空”在那儿没被包裹。
- 检查父容器在开发者工具「Computed」里 height 是否异常小（如
0px或auto却明显撑不开） - 确认后续元素没有意外设置
margin-top: -XXpx主动上移 - 排除
position: absolute或transform导致的视觉偏移干扰
用 display: flow-root 让父容器自动包含浮动
这是现代标准解法：不增加 DOM、不裁剪内容、语义清晰。它强制父容器创建 BFC（块级格式化上下文），使浮动子元素参与高度计算。
- 写法：
.container { display: flow-root; } - 兼容性：Chrome 58+、Firefox 53+、Safari 15.4+、Edge 79+；IE 完全不支持
- 比
overflow: hidden安全——后者一旦子元素超出宽高（如下拉菜单、tooltip），会被静默截断 - 如果项目需兼容 Safari overflow: auto 替代，但要加
max-height: none防滚动条误触发
必须用 clear: both 时，加在哪？
clear 不是加在浮动元素自己身上，也不是加在后续第一个块级元素上（容易漏或错位），而是加在浮动内容的末尾、父容器内部的“收口处”。
立即学习“前端免费学习笔记（深入）”；
- 推荐伪元素方式，避免冗余 HTML：
.container::after { content: ""; display: table; clear: both; } - 若结构受限必须用空标签，放在父容器最底部：
<div style="clear: both;"></div> - 绝对不要给后续内容（如
<p>TESTTEST1212</p>）加clear: both——它本不该为浮动“负责”，且一旦浮动结构变化，这个clear就失效
真正容易被忽略的点
很多人修完“覆盖”问题就停手，但浮动元素本身是否还在文档流中、是否影响交互、是否和 z-index 配合出错，常被跳过。比如下拉菜单被盖住，往往不是 z-index 不够，而是浮动父容器没设 position: relative，导致子菜单定位基准跑到 上。修复浮动布局，本质是恢复文档流秩序——清除浮动只是手段，理解“谁该撑高、谁该定位、谁该建立层叠上下文”，才是不反复踩坑的关键。
