overflow: hidden 触发bfc后，普通流元素自动避开浮动区域；因其使元素进入新块级格式化上下文，遵循“bfc区域不与float box重叠”规则，从而避免被浮动元素覆盖。
overflow: hidden 触发BFC后，普通流元素自动避开浮动区域
当一个元素设置了 float: left 或 float: right，它会脱离文档流，后续的块级元素（如 <p></p>、<div>）默认会“无视”它的存在，从顶部开始布局，造成文字或盒子被浮动元素覆盖——这不是 bug，是 CSS 规范行为。
<p>解决的关键不是强行位移，而是让后续元素“意识到”浮动元素的存在。给该后续元素设置 <code>overflow: hidden（或其他触发 BFC 的属性），它就进入一个新的块级格式化上下文，此时 BFC 的布局规则生效：BFC 区域不会与 float box 重叠。
实操建议：
- 只对需要避开浮动的元素本身加
overflow: hidden，不是给父容器（除非父容器也需包裹浮动子项） - 避免在有滚动需求的容器上用
overflow: hidden，可改用overflow: auto或display: flow-root（更现代且无副作用） - 若元素本身已有
position: absolute或float，它已天然处于 BFC，无需额外处理
display: flow-root 是更干净的 BFC 触发方式
display: flow-root 是专为创建无副作用 BFC 设计的值，2018 年起已被 Chrome/Firefox/Safari 全面支持（IE 不支持）。相比 overflow: hidden，它不隐藏溢出内容，也不影响滚动行为，语义清晰。
常见误用：
- 写成
display: flex虽然也触发 BFC，但会改变内部子项的布局模型（变成 flex 容器），可能破坏原有 margin/padding 行为 - 用
float自身触发 BFC：会让该元素脱离文档流，通常不是你想要的效果 - 用
position: absolute：同样脱离文档流，且脱离后不再参与父容器高度计算
推荐写法：div.content { display: flow-root; }
为什么父容器加 overflow:hidden 可能“看起来有效”，但逻辑不同
很多人给浮动元素的父容器加 overflow: hidden，发现父容器高度“撑开”了，浮动子项也被包住了——这其实是 BFC 的另一条规则在起作用：计算 BFC 高度时，浮动元素也参与计算，即“清除浮动”。但这和“避开覆盖”是两个问题。
关键区别：
- 父容器加
overflow: hidden→ 解决的是父容器高度塌陷，不解决兄弟元素被覆盖 - 被覆盖的兄弟元素自身加
overflow: hidden或display: flow-root→ 才真正触发“BFC 区域不与 float box 重叠”规则 - 如果同时存在高度塌陷 + 兄弟覆盖，需分别处理：父容器触发 BFC 清除浮动，兄弟元素再单独触发 BFC 避开
移动端适配中容易忽略的 overflow:auto 兼容性细节
在 iOS Safari 和部分 Android WebView 中，overflow: auto 触发 BFC 的行为稳定，且支持惯性滚动；但若容器内无足够内容高度，某些旧版内核可能不渲染滚动条，导致 BFC 未实际生效（极少数情况）。
稳妥做法：
- 优先使用
display: flow-root（现代项目） - 兼容老浏览器时，用
overflow: hidden+ 显式设置最小高度（如min-height: 1px）确保 BFC 稳定建立 - 避免依赖
overflow: scroll，它在 iOS 上强制显示滚动条，影响 UI
BFC 不是黑魔法，它只是 CSS 布局引擎的一组明确规则。真正容易被忽略的，是混淆“谁需要触发 BFC”——是被覆盖者，不是浮动者，也不是无关的祖父容器。
