块级元素默认不触发bfc，仅作为内容参与者；行内元素完全无法触发bfc；bfc触发取决于计算后的display/position/float值，与标签名无关；vertical-align在bfc内对非行内盒无效。
块级元素默认不触发BFC，但能参与BFC容器的布局
块级元素本身不是BFC触发器，<div>、<code><p></p>、<section></section>这些元素即使设了width和margin，也不会自动创建BFC。它们只是BFC的“内容参与者”——如果父容器已触发BFC（比如overflow: hidden），那块级子元素的margin就不会和外部塌陷，浮动也不会溢出。
常见误判：看到<div>能包裹内容、撑开高度，就以为它自带BFC。实际它只是块容器（block container），不是BFC容器（BFC root）。
<ul><li>验证方式：给父<code><div>加<code>border: 1px solid red，再放一个浮动子元素，若子元素撑不出父容器边界，说明父已触发BFC；否则没触发
<div>设<code>float: left，却指望它阻止父容器高度塌陷——不行，必须让父容器自己触发BFC
display: flow-root是现代写法，IE不支持；老项目优先用overflow: hidden或float
行内元素完全无法触发BFC，且不能作为BFC根节点
<span></span>、<a></a>、<strong></strong>这类纯行内元素，无论加什么CSS，都不可能成为BFC根节点。规范明确限定：只有特定display值或定位/浮动状态才能触发BFC，display: inline不在其中。
容易混淆的点：<img>虽是行内元素，但它属于“可替换元素”，设display: block后能触发BFC——但起作用的是display值，不是<img>本身。
- 错误尝试：对
<span></span>设overflow: hidden，无效；设position: absolute，它脱离文档流了，也不再是BFC触发上下文中的“容器” - 真实可用路径：把行内元素包一层
<div>，再对该<code><div>触发BFC；或直接改其<code>display为inline-block或block - 性能提示：
display: inline-block会触发BFC，但可能引入空白符问题；display: flow-root更干净，无副作用 -
display: block→ 不触发BFC -
display: inline-block→ 触发BFC -
display: flow-root→ 显式触发BFC（推荐） -
float: left→ 触发BFC（哪怕原是<span></span>） -
position: absolute→ 触发BFC（但脱离文档流） -
overflow: auto→ 触发BFC（最常用） - 修复方法：给需要对齐的元素加
display: inline-block，再配vertical-align - 替代方案：用
flex或grid布局，它们不依赖line box，align-items更可控 - 关键提醒：BFC本身不提供垂直居中能力，它只是“隔离环境”。想居中，得靠内部布局机制，不是靠BFC
BFC触发条件与元素类型无关，只看计算后的display/position/float值
BFC是否建立，取决于最终渲染树中该节点的**计算样式**，和HTML标签名、原始display默认值完全无关。一个<span></span>设成display: table-cell，就能触发BFC；一个<div>设成<code>display: inline，就失去块容器能力，更别说BFC。
调试时别被标签名带偏——打开DevTools，看Computed面板里的display值，再对照六种触发条件：
vertical-align在BFC内外的表现差异极易被忽略
vertical-align只对行内盒、表格单元格、inline-block盒生效，而BFC容器会切断行内格式化上下文——这意味着：在一个已触发BFC的父容器里，子元素即使设了vertical-align: middle，只要它不是inline或inline-block，就完全无效。
典型场景：用overflow: hidden解决浮动塌陷后，发现里面<span></span>的vertical-align失灵了——不是bug，是BFC阻断了line box传播。
