Flex容器必创建BFC，具备阻止外边距合并等特性；子项不自动创建BFC，但自身触发BFC不影响flex布局；flex内部无margin collapse，无需用BFC解决；嵌套时绝对定位+BFC需注意containing block差异。
Flex容器自动创建BFC
Flex容器（即 display: flex 或 display: inline-flex 的元素）在规范中明确要求**必须建立新的块级格式化上下文（BFC）**。这不是浏览器实现差异，而是 CSS Flexbox 规范强制行为。这意味着：只要一个元素设了 display: flex，它就天然具备 BFC 的全部特性——比如阻止外边距合并、包含浮动子元素、独立于外部布局流等。
常见误解是“只有 display: flow-root 或 overflow: hidden 才能触发 BFC”，其实 display: flex 是更早、更确定的 BFC 创建方式之一，且无需额外 hack。
BFC 与 Flex 子项的层叠关系不冲突
Flex 子项（flex-item）本身不自动创建 BFC，它们的层叠行为由父容器的 flex formatting context 管理。但若某个子项自己也触发了 BFC（比如加了 overflow: auto），它不会因此脱离 flex 布局——BFC 只影响其内部渲染和与兄弟/祖先的外边距交互，不影响它作为 flex item 接受 order、flex-grow 等属性控制。
容易踩的坑：
立即学习“前端免费学习笔记（深入）”；
- 误以为给 flex 子项加
z-index就能随意盖住其他子项——其实必须先让该子项成为定位元素（如position: relative），否则z-index无效 - 在 flex 容器内对子项使用
float：float 在 flex context 中被忽略，且不会触发 BFC（因为 float 不再起作用）
用 BFC 解决 Flex 容器内的 margin collapse 问题？没必要
Flex 容器内部根本不存在传统文档流中的垂直 margin 合并（margin collapsing）。因为 flex items 不参与块级流，它们的外边距按 flex 轴线独立计算，不会发生相邻块级元素间的合并行为。
所以当你看到两个 flex 子项之间距离异常小，大概率不是 margin collapse，而是：
- 子项用了
margin-bottom但父容器没设gap，导致视觉上“挤在一起” - 子项本身是空元素或只含换行符，被压缩成高度为 0
- 字体大小或行高影响了基线对齐，造成视觉错位（尤其混用
input和label时）
这时候强行加 overflow: hidden 去“触发 BFC”不仅多余，还可能意外截断内容或影响滚动行为。
真正需要关注的边界情况：嵌套 flex + BFC 冲突
当 flex 容器的某个子项同时满足两个条件：① 是定位元素（position: absolute）；② 自身又创建了 BFC（如 overflow: hidden），它的尺寸计算会脱离 flex 主轴约束，但依然受父容器的 clip 或 contain 影响。
典型表现是：绝对定位子项宽度设为 100%，却只占满父容器 content box，而不是包括 padding 的区域——这是因为 BFC 的包含块（containing block）在绝对定位下由最近的定位祖先决定，而 flex 容器的 containing block 逻辑与普通块级容器不同。
这种细节在复杂表单弹层、下拉菜单或 Tooltip 组件中容易暴露，调试时建议优先检查 position 层级和 containing block 的来源，而不是归因于“BFC 和 Flex 不兼容”。
