直接给父容器加 overflow: hidden 不总管用，因为它仅裁剪溢出内容、不解决浮动脱离文档流本质，且在 fixed/transform、Flex/Grid 嵌套、旧版 Safari 中存在兼容性与定位异常问题。
为什么直接给父容器加 overflow: hidden 不总管用
因为 overflow: hidden 会裁剪超出边界的子元素（比如下拉菜单、tooltip、fixed 定位的遮罩层），在多层嵌套中，上层容器可能无意中截断了下层组件的视觉呈现。更麻烦的是，它不解决浮动脱离文档流的本质问题——只是“假装看不见”，导致后续布局计算失真，尤其在 JS 动态插入内容或响应式重排时容易出错。
- 当子元素使用
position: fixed或transform触发新层叠上下文时，overflow: hidden可能意外改变其定位参考系 - Flex/Grid 容器内部再嵌套浮动元素时，
overflow失效（现代布局模式下浮动本就不该主导结构） - 部分旧版 Safari 对
overflow: hidden+zoom: 1组合有渲染 bug，造成文字模糊或重绘异常
什么时候必须用 clearfix 而不是伪元素单写 ::after
当你需要在多个嵌套层级中「逐级隔离浮动影响」时，clearfix 是唯一可控手段。单写 ::after 只作用于当前元素，而复杂布局中，某一层的浮动可能穿透数层父容器，直到遇到第一个具备 BFC 的祖先才被“兜住”——但你无法保证那个祖先恰好是你想控制的层级。
- 典型场景：CMS 页面中，
.article-content内部嵌套.quote-box，后者又含.avatar-float-left；若只在.quote-box上加::after，.article-content仍会高度塌陷 -
clearfix类必须显式加到每一级需要包裹浮动的容器上，不能依赖继承或自动传播 - 推荐用 SCSS 混合宏封装：
@mixin clearfix { &::before, &::after { content: ""; display: table; } &::after { clear: both; } }，避免手写重复代码
clear: both 放在 ::after 还是 ::before？差别在哪
必须放在 ::after。放在 ::before 会导致清除行为发生在内容之前，无法撑开父容器高度——因为浮动元素仍在父容器内流中“悬空”，::before 清除的是它上方并不存在的浮动，对父容器高度无贡献。
-
::after插入在所有子元素末尾，clear: both强制它换行到底部，从而把父容器高度拉伸到包含全部浮动元素 - 如果同时用
::before和::after（如经典 clearfix），::before仅用于防止顶部外边距合并（margin collapse），和清除浮动无关 - 现代写法可精简为仅
::after：.clearfix::after { content: ""; display: block; clear: both; }，兼容性足够（IE8+）
嵌套过深时，clearfix 导致的 margin/padding 计算异常怎么查
根本原因是：每个 clearfix 容器的 ::after 生成了一个 display: block 元素，它会参与盒模型计算。当多层嵌套且各层都设了 padding 或 margin，这些伪元素会叠加额外空白，尤其在使用 box-sizing: border-box 时更难察觉。
立即学习“前端免费学习笔记（深入）”；
- 调试技巧：在 DevTools 中勾选「Show user agent shadow DOM」，能看到每个
::after的实际尺寸和位置 - 避免方案：对已知不需要撑高（如仅用于清除内部浮动，自身高度由其他子元素决定）的容器，改用
display: flow-root（Chrome 64+/Firefox 59+），它创建 BFC 且不引入伪元素 - 兼容性兜底：用
@supports not (display: flow-root) { .clearfix { ... } }条件加载传统 clearfix
真正麻烦的从来不是加不加 clearfix，而是哪一层该加、哪一层其实该用 display: flex 或 display: grid 替代浮动——但 legacy 项目里，你得先看清 DOM 树里哪个 div 正在悄悄塌陷。
