BFC能包含浮动元素是因为W3C规范强制要求BFC容器在计算高度时必须纳入浮动子元素的几何边界，而非主动“拉住”浮动；普通容器因浮动脱离文档流而高度塌陷，BFC则通过切换渲染规则使浮动参与高度计算。
为什么BFC能包含浮动元素
BFC本身不“主动包含”浮动元素，而是浏览器在渲染时，对触发BFC的容器执行了一条硬性规则：计算该容器高度时，必须把内部所有浮动元素的几何边界纳入考量。这不是CSS样式“拉住”了浮动，而是格式化上下文的定义强制改变了高度计算逻辑。
BFC容器高度计算 vs 普通容器
普通块级容器（非BFC）在计算自身高度时，只考虑参与普通流（normal flow）的子元素；而浮动元素已脱离普通流，因此被忽略——导致父容器高度塌陷为0。
BFC容器则不同：W3C规范明确要求，在BFC中，浮动元素仍被视为影响容器尺寸的成员。这意味着：
- 浮动子元素的 top / bottom 边界会被用于确定BFC容器的 content height
- 即使子元素
float: left，只要父元素有overflow: hidden，其高度就会撑开 - 这个行为与
clear: both无关——后者只是清除后续元素的浮动影响，不改变父容器高度计算
容易被误解的几个点
开发者常误以为“设置了 overflow: hidden 就是让父容器‘挡住’了浮动”，其实不是视觉遮挡，而是布局规则切换：
-
overflow: visible（默认）→ 容器不创建BFC → 高度不包含浮动 -
overflow: auto或hidden→ 触发BFC → 高度包含浮动 - 用
display: inline-block同样触发BFC，也能撑高，但会带来额外的行内布局副作用（如换行、空白符占位） - IE6/7 不支持BFC，靠
zoom: 1触发 hasLayout 实现类似效果，但原理不同
真正起作用的是“格式化上下文类型”，不是某个CSS属性
关键要意识到：float、position: absolute、overflow: hidden 等，都只是“触发BFC的手段”，而非“解决方案本身”。真正解决问题的是浏览器进入BFC渲染模式后，整套布局规则的切换——包括高度计算、margin处理、浮动容纳等，是一揽子行为。
所以别只记“overflow:hidden能清浮动”，得理解它背后切换了整个格式化上下文；否则遇到 display: flex 子项浮动失效、或 contain: layout 干扰BFC等情况，就容易卡壳。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
