清除浮动本身不改变动画逻辑，但选错方法会导致卡顿、裁剪或层级错乱；overflow:hidden会裁剪transform动画元素并抑制硬件加速，clear:both引发O(n)回溯拖慢帧率，推荐display:flow-root或直接迁移到Flex/Grid布局。
清除浮动本身不改变动画逻辑，但选错方法会让动画卡顿、裁剪或层级错乱。
overflow: hidden 清除法会裁剪动画帧
用 overflow: hidden 触发 BFC 是常见清除方式，但它会严格裁剪超出容器边界的所有内容——包括正在执行位移、缩放或旋转的动画元素。
- 典型现象：
.card { float: left; } .tooltip { position: absolute; right: -20px; }→ tooltip 被截断，hover 动画“突然消失” - 更隐蔽的问题：某些浏览器在
overflow: hidden容器内对transform动画做合成层判断更保守，导致本该硬件加速的动画降级为软件绘制 - 如果动画依赖
z-index或层叠上下文（比如弹窗盖在卡片上），overflow: hidden会强制创建新层叠上下文，可能让弹窗被压在底层
clear: both 会扩大重排范围，拖慢动画响应
clear: both 不直接参与动画，但它在布局阶段触发 O(n) 回溯扫描——每次窗口 resize、DOM 插入或样式变更，浏览器都得从当前元素向上检查所有浮动兄弟节点的位置。
- 滚动加载场景下，每插入一个
clear: both卡片，重排范围就扩大一次，动画帧率明显下降 - 和
transform动画共存时尤其危险：哪怕只动transform，只要父容器有clear: both，浏览器仍可能因浮动上下文未稳定而放弃缓存 layout 结果 - 替代方案：改用
clear: left或clear: right（如果浮动方向明确），减少回溯深度
伪元素清除法不是万能解药
.clearfix::after { content: ""; display: block; clear: both; } 比加空 <div> 干净，但它依然依赖 <code>clear 语义，所以同样触发回溯扫描。
- 真正起作用的是配合
display: flow-root或overflow: hidden主动创建 BFC，把重排锁死在容器内 - 现代写法应优先用
.clearfix { display: flow-root; }—— 无需伪元素，不触发clear回溯，动画容器更“干净” - 兼容性注意：
display: flow-root在 Safari 10.1+ / Chrome 58+ / Firefox 53+ 支持；IE 完全不支持，Edge 16+ 起支持
最容易被忽略的一点：清除浮动从来不是目的，而是对错误布局模式（float）的补救。只要还在用 float 做整体布局，无论怎么清除，动画和性能隐患就始终存在。Flex 和 Grid 的 layout 计算可缓存、增量更新粒度细、不依赖全局浮动上下文——这才是让动画真正流畅的底层保障。
