浮动导致父容器无高度，min-height失效；clearfix通过伪元素提供高度锚点使其生效，overflow:hidden仅触发BFC但未必产生高度；Flex布局中需注意align-items:stretch被height声明关闭。
浮动元素让父容器“看不见”高度，min-height 失效是结果不是原因
设置了 min-height 却没撑开，根本不是 min-height 写错了，而是父容器压根没高度可算——因为所有子元素都 float: left 或 float: right，全部脱离文档流。浏览器计算父容器 height: auto（包括 min-height 的基准）时，只看还在流里的内容：比如一段文字、一个未浮动的 <span>。哪怕你给浮动子元素写了 height: 500px，父容器也当它不存在。
常见现象包括：min-height 在 Computed 面板里显示正常，但父容器视觉上只有一条线高；背景色不显示；后续兄弟元素叠在上面；滚动条没出现但内容“消失”了。
为什么 clearfix 能救 min-height，而 overflow: hidden 不一定可靠
.clearfix::after 生效的关键在于它插入了一个**真实参与文档流的块级伪元素**，并用 clear: both 强制它下移到所有浮动元素下方，形成一个“底部锚点”。这个锚点哪怕 height: 0，也会把父容器的 height: auto 基准拉下来，此时 min-height 才有作用空间。
overflow: hidden 是靠触发 BFC 来包含浮动，但它本身不提供高度锚点。如果父容器内部除了浮动元素外完全为空（没有文字、没有 padding、没有 border），BFC 虽然生效，但容器仍可能渲染为 height: 0，min-height 就还是没机会触发。
立即学习“前端免费学习笔记（深入）”；
-
overflow: auto比hidden更稳妥，会强制生成滚动机制，间接保障最小渲染高度 - 若父容器有
border或padding，overflow: hidden通常也能让min-height显效 - 但只要存在内容溢出风险（如下拉菜单、Tooltip），
overflow: hidden就不该用
Flex 替代方案中 min-height 失效的隐藏开关
把父容器改成 display: flex 确实能绕过浮动塌陷，但别急着以为 min-height 就自动好了——子元素只要显式写了 height、min-height 或 max-height，就会关闭 align-items: stretch，导致它不再拉伸填满父容器交叉轴，min-height 也就失去上下文。
调试时快速验证：
– 临时删掉子元素的所有 height/min-height 声明，看是否立刻等高
– 检查父容器 computed height 是否为 auto 或具体像素值（如果是 0px，说明上层高度链断了）
– 在 flex-direction: column 下，align-items: stretch 控制的是宽度，跟高度无关，别在这儿浪费时间
- 正确做法：父容器设
min-height: 100vh，子元素用flex: 1或align-self: flex-start+min-height: 200px - 避免写
height: 100%—— 它依赖父容器高度已定义，否则算出来是0，还顺手封死拉伸
绝对定位和浮动混用时，min-height 的优先级陷阱
一个容器里既有浮动子元素，又有一个 position: absolute 的弹窗，这时 min-height 很可能只按浮动部分计算，而忽略绝对定位块——因为两者脱离文档流的方式不同：浮动仍参与行盒布局，绝对定位则彻底游离。浏览器对它们的“可见性”处理不一致。
更隐蔽的问题是：如果绝对定位元素写了 top: 0; bottom: 0，它会强行拉伸占满父容器可用空间，此时父容器的 min-height 可能被绕过，哪怕父容器本身设置了 min-height: 400px，最终渲染高度也可能由绝对定位子元素决定。
- 不要指望
min-height同时约束多种脱离流的子元素，它们各自独立响应 - 混合布局时，优先统一为一种脱离方式（全用 Flex/Grid，或全用定位+包含块控制）
- 真要混用，把绝对定位元素的包含块单独抽成一个
position: relative的 wrapper，和浮动区域解耦
真正容易被忽略的，是开发者常把 min-height 当成“兜底保险”，却忘了它生效的前提：父容器必须处于一个能产生可计算高度的布局上下文中。浮动、绝对定位、Flex 的拉伸开关……这些不是干扰项，就是规则本身。调样式前，先确认容器有没有“高度感”。
