父容器height为0px或远小于预期是浮动导致塌陷的最准最快判断依据；因浮动元素脱离文档流，父容器计算高度时直接忽略它们，属CSS规范行为而非bug。
直接看父容器的 height 是否为 0px 或远小于预期——这是最准、最快、不依赖工具的判断依据。
用 DevTools 快速定位塌陷父容器
浮动元素脱离文档流，父容器计算高度时会忽略它们，导致 height 显示为 0px 或几像素。这不是 bug，是 CSS 规范行为。
- 按
Ctrl+Shift+C（Win）或Cmd+Shift+C（Mac），点选疑似错位区域中的任意子元素 - 在 Elements 面板中逐级向上点击父节点，在右侧 Computed 面板紧盯
height值 - 一旦发现某个
<div>、<code><section></section>的height是0px，但内部有float: left或float: right元素，基本锁定问题源头 - 再确认该父容器的
overflow是visible（默认值），且display是block→ 说明它既没触发 BFC，也没做清除 - 在 Console 中运行：
$$('div, section, article, header, footer, aside, main, p, h1, h2, h3, h4, h5, h6').forEach(el => el.style.border = '1px solid #f00') - 重点关注三类异常：
— 父容器红框“断开”，但内部浮动子项红框完整延伸到右边缘 → 父容器未包裹子项，需触发 BFC
— 文字容器红框从顶部就被截断，文字从浮动图下方“钻出来” → 缺少清除或未创建新 BFC
— 多个并排浮动项中，某一个底部红框明显更低 → 可能内部有未闭合标签、margin-bottom没撑开父级，或盒模型计算溢出 - 把
clear: both写在浮动元素自身样式里（如.float-item { clear: both; }）→ 它只影响自己位置，不反馈给父容器 - 清除节点是
display: inline或display: flex元素 →clear对非块级元素无效 - 浮动元素后面根本没放任何兄弟块级元素（HTML 中直接闭合了父容器）→ 没地方可清
- 清除节点被
display: none或visibility: hidden隐藏 → 样式存在，但不参与布局 - 检查 DevTools Styles 面板，确认
.clearfix::after规则未被 strike-through（被覆盖） - 必须同时满足三项：
content: ""（不能是none）、display: table（比block更稳妥）、clear: both（单侧left/right在两栏布局中会漏清） - 若父容器设置了
height、max-height或overflow: hidden，会压制清除后的高度撑开效果 - 若父容器是
position: absolute或fixed，它本身已脱离文档流，清除动作失去意义
用边框法视觉暴露“谁没兜底”
不改代码、不刷新页面，靠视觉快速识别哪些父容器没包裹住浮动子项。
检查 clear: both 是否加在错误位置
clear: both 不是对浮动元素生效，而是让「当前元素」避开前面所有浮动的影响。加错地方等于没加，甚至打断正常流。
立即学习“前端免费学习笔记（深入）”；
验证 .clearfix::after 是否真正生效
很多项目写了 .clearfix 却失效，问题常出在伪元素规则本身或父容器干扰上。
真正难的不是找到哪个父容器塌陷，而是判断它是否本该由清除浮动来兜底——比如父容器其实已被 display: flow-root 或 overflow: auto 覆盖，此时再加 .clearfix 就是冗余；又或者浮动只是历史残留，子元素实际已在 Flex/Grid 容器中，float 早已被浏览器忽略为 none。这些细节，只有在 Layout 面板里盯着真实 height 和 computed float 值才能确认。
