height: 200px强制渲染固定高度，不响应内容变化，与自适应无关；它绕过塌陷但无法处理文字增多、图片加载、JS动态增删等场景，而overflow: hidden或clearfix才真正参与布局、重建BFC并包含浮动子项。
给父级设置固定 height 不能解决“自适应”问题，它只是绕过塌陷，而非修复布局逻辑。
为什么 height: 200px 会让父容器“看起来正常”
因为 height 是强制值，浏览器直接按指定像素渲染，不再尝试计算内容高度。父容器不再依赖浮动子项的尺寸，自然不会塌陷——但这和“自适应”完全无关。
- 子元素实际高度变化（比如文字增多、图片加载完成）时，内容会溢出或被裁剪
- 响应式场景下，
height很难适配不同屏幕或字体缩放 - 维护成本高：每个浮动组合都要人工测算并硬编码高度
哪些情况会立刻暴露 height 的缺陷
只要浮动子项的高度不是完全静态，height 就会失效：
- 子元素含可变行数文本（
line-height+font-size变化） - 图片异步加载完成前占位高度为 0，加载后撑开但父容器已锁定高度
- JavaScript 动态插入/删除浮动子项，高度无法同步更新
- 使用
min-height替代height？它只设下限，仍不解决“自动取最大值”的需求
height 和 overflow: hidden / clearfix 的本质区别
height 是覆盖行为，overflow: hidden 和 clearfix 是参与布局的行为：
立即学习“前端免费学习笔记（深入）”；
-
height: 200px—— 告诉浏览器：“别管里面有什么，就画 200px 高” -
overflow: hidden—— 触发 BFC，让父容器重新包含浮动子项的边界 -
.clearfix::after—— 插入一个真实块级元素，用clear: both把父容器底部“拉下来”
前者放弃布局权，后者保留文档流参与权——这是能否响应内容变化的关键分水岭。
真正卡住的点，往往不是写错 height 值，而是误以为“高度显示出来了”就等于“布局修复了”。一旦内容动态性出现，硬编码高度就成了第一个崩坏环节。
