父容器未触发bfc是因自身样式不满足条件，而非子元素浮动所致；必须显式设置overflow:hidden、display:flow-root、flex或grid等属性才能形成bfc并包含浮动子项。
浮动布局本身不会“阻止”父容器触发 BFC，而是父容器**默认不满足触发条件**——float 是子元素的属性，它对父容器是否形成 BFC 没有直接影响；真正决定父容器能否包含浮动子项的，是父容器自身的 CSS 属性是否满足 BFC 触发条件。
为什么父容器明明有浮动子元素，却没形成 BFC？
因为 BFC 的触发取决于父容器自己的样式，不是子元素有没有 float。一个 div 即使里面全是 float: left 的子项，只要它自身是 display: block 且 overflow: visible（默认值），它就**不构成 BFC**。
-
overflow: visible是绝大多数块级元素的初始值，而它明确不触发 BFC -
float、position: absolute等属性作用在子元素上，无法让父容器“被动”进入 BFC - 开发者常误以为“加了 float 就该被包裹”，但规范里从没这回事——浮动本意是文字绕排，不是布局容器机制
哪些父容器样式能真正触发 BFC？
必须显式设置以下任一属性，父容器才会创建 BFC，从而包含浮动子项高度：
-
overflow: hidden或auto或scroll—— 最常用，但会裁剪溢出内容 -
display: flow-root—— 专为此设计，无裁剪副作用，现代项目首选 -
display: flex或display: grid—— 它们天然创建 BFC，且子项不再受float影响（computed 值变为none） -
position: absolute或fixed—— 但会让父容器自己脱离文档流，问题上移，不推荐
为什么 clear: both 加在父容器上完全无效？
clear 不是 BFC 触发器，它只对**处于同一浮动上下文中的后续兄弟元素**生效。给父容器设 clear: both，等于让它“清除自己内部的浮动”——语法合法，但逻辑不成立，浏览器直接忽略。
- 正确用法：在浮动元素之后、仍处于文档流中的下一个块级元素上加
clear: both - 伪元素方案（如
.clearfix::after）之所以有效，是因为它插入了一个新块级元素，并让它参与流、执行clear，从而把父容器底部“拉下来” - 如果父容器自己也设了
float或position: absolute，那它已脱离文档流，再加clearfix也没用
真正容易被忽略的点是：float 从来就不是布局工具，它只是文本环绕的遗留机制。2026 年还在靠它撑开父容器，本质上是在用错工具解决本不该存在的问题——display: flow-root 一行代码就能终结塌陷，而 flex 或 grid 则让“清除浮动”这个概念彻底过时。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
