float强制元素脱离文档流后，浏览器需单独维护浮动上下文、逐行重算line box宽度以支持文字绕行、响应尺寸变化时重新定位，并在重排时无法缓存布局数据，导致隐性性能开销。
不建议在现代 CSS 布局中大量使用 float，根本原因不是它“过时”，而是它强制元素脱离文档流后引发的连锁反应——父容器塌陷、清除逻辑冗余、响应式行为不可控，且浏览器仍需为浮动元素维护额外的布局上下文，带来隐性性能开销。
float 脱离文档流后，浏览器要多做哪些事？
当一个元素设置 float: left 或 float: right，它不再参与父容器的高度计算，但浏览器仍必须：
- 为该浮动元素单独维护一个“浮动上下文”（float context），记录其位置、尺寸、与相邻浮动元素的碰撞关系
- 对后续每一行内内容（line box）重新计算可用宽度，以实现文字绕行——即使页面里没有文本，这个计算流程也照常触发
- 在每次重排（reflow）时，检查所有浮动元素是否因父容器尺寸变化而需要重新定位（比如窗口缩放）
- 若存在多个浮动兄弟元素，还需按 HTML 顺序逐个解析其堆叠和对齐关系，无法像 Flex/Grid 那样批量优化
overflow: hidden 和 display: flow-root 清除浮动，性能差在哪？
两者都能让父容器包含浮动子元素，但底层机制不同，影响也不同：
-
overflow: hidden会强制创建一个新的层叠上下文（stacking context）和包含块（containing block），在 Safari 旧版本或低端设备上可能触发不必要的合成层（compositing layer），增加内存占用和绘制耗时 -
display: flow-root虽然语义干净（只创建 BFC），但它在部分 Chrome 版本（如 Chrome 80–95）中会导致子元素的position: absolute定位参考点异常，间接引发重排 - 无论用哪种清除方式，只要父容器内有浮动元素，它的
getBoundingClientRect()和offsetHeight就无法被浏览器安全缓存——每次读取都可能触发同步布局计算
Flex/Grid 容器里写 float: left，会发生什么？
规范明确要求：在 display: flex 或 display: grid 的直接子元素上设置 float，该属性会被忽略（no effect），clear 同样无效。但注意两个例外：
立即学习“前端免费学习笔记（深入）”；
- 如果浮动写在 flex/grid 子项的**内部元素**上（比如
.card > img { float: left; }），它只影响那个子项内部的文字流，不会干扰外部 flex 排列——此时绕行逻辑照常，但父 flex 容器完全不感知 - 若外层是 flex，内层又嵌套了
float+clear，而 clear 目标是另一个已脱离文档流的元素（比如position: absolute），那clear会彻底失效，且无任何报错提示
图文混排场景下，float 还值得保留吗？
纯图文环绕（比如新闻正文里一张左图右文）仍是 float 最自然的适用场景，但要注意：
- 不要把
float和响应式宽度混用（如width: 50%+float: left），小屏下容易因四舍五入导致换行错乱 - 避免在
float元素上同时设margin和transform，某些 Firefox 版本会跳过绕行计算，文字直接穿透浮动框 - 如果图文区域需等高、对齐或响应式切换为垂直堆叠，
float会立刻变成维护黑洞——此时改用display: grid配合grid-template-areas更可控
真正难处理的不是 float 本身，而是它和文档流“半脱离”的状态：既不完全退出，又不完全参与。这种模糊地带在复杂嵌套或动态渲染中极易放大误差，而现代布局模型（Flex/Grid）从设计上就拒绝这种中间态。
