clearfix在overflow: visible且存在transform等属性时失效，因伪元素被隔离进新层叠上下文而无法感知浮动；应改用display: flow-root或overflow: auto触发bfc，避免伪元素冲突。
为什么clearfix在overflow: visible时反而失效
当父容器同时设置了overflow: visible和transform、filter或will-change时，伪元素::after的清除行为可能被层叠上下文隔离——它仍渲染，但clear: both不再能“感知”到浮动元素的位置，导致撑高失败。这不是浏览器 bug，而是 CSS 规范中层叠上下文对浮动清除逻辑的限制。
-
overflow: visible本身不触发 BFC，所以依赖伪元素清除；但一旦叠加视觉修饰属性，伪元素会被包裹进新层叠上下文，脱离原始浮动流 - 开发者工具里能看到
::after节点存在，但 computedclear值为none（实际被忽略） - 常见于使用
transform: translateY()做微调、或filter: drop-shadow()加阴影的浮动容器
如何让clearfix在transform/overflow混合场景下生效
关键不是“修复”伪元素，而是避免让它陷入冲突的渲染上下文。最直接的办法是把触发 BFC 的责任从伪元素转移到容器自身。
- 优先用
display: flow-root替代clearfix：它不依赖伪元素，也不受transform影响，一行生效且无副作用 - 若必须兼容旧浏览器，改用
overflow: auto代替visible——注意不是hidden，auto既能触发 BFC，又保留溢出内容可见性 - 如果
transform仅用于动画，可将它移到子元素上，而非父容器；父容器保持干净，clearfix::after就能正常工作
overflow: hidden + clearfix 同时写会怎样
两者共存时，overflow: hidden会立即触发 BFC 并裁剪内容，而clearfix::after根本不会执行清除动作——因为 BFC 已建立，浮动子项高度已被包含，伪元素的clear失去作用对象。结果是：高度撑开了，但下拉菜单、tooltip 全被裁掉，且开发者容易误以为“双重保险更稳”。
-
overflow: hidden和clearfix是互斥方案，不是叠加关系 - 检查 CSS 文件，删除其中一项；如已上线，优先删
overflow: hidden，保留clearfix并补全display: table和height: 0 - 特别注意 PostCSS 或 Tailwind 自动生成的 utility class，有些会悄悄注入
overflow: hidden，与手写clearfix冲突
移动端 Safari 下 clearfix 失效的隐蔽原因
iOS 15.4+ 支持display: flow-root，但部分老项目仍用clearfix，而在 Safari 中，若父容器设了overflow-x: hidden且子元素有横向滚动需求，::after的clear: both可能被忽略——因为 Safari 对overflow-x和clear的交互处理较特殊。
- 不要单独设
overflow-x: hidden，改用overflow: hidden（同时禁用 x/y）或overflow-x: hidden; overflow-y: visible显式声明 - 若需横向滚动，放弃
clearfix，改用display: flow-root或flex布局 - 验证方式：在 Safari 开发者工具中临时删掉
overflow相关声明，看clearfix是否恢复生效
clearfix，而是判断它该不该出现——很多所谓“失效”，其实是布局方式早该升级了。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
