浮动元素不覆盖文字是设计使然，因其语义定位为“图文环绕”，浏览器在生成line box时将浮动区域视作不可用空间，强制收缩行宽排版；而绝对定位则彻底退出文档流。
浮动元素不覆盖文字是设计使然，不是 bug
浮动元素不会覆盖行内文字，是因为它的语义定位就是“图文环绕”——float 从诞生起就不是为了遮盖内容，而是为了让文本、span、em 这类行内级内容能自动绕开它排版。浏览器在生成每一行文字（即 line box）时，会把浮动区域视作不可用空间，强制收缩该行宽度，在剩余空白中排列文字。
这和 position: absolute 完全不同：绝对定位元素彻底退出文档流，后续块级元素会无视它，文字也可能被直接盖住；而浮动元素虽脱离普通文档流，却仍参与行框（inline formatting context）布局，这是 CSS 2.1 明确定义的行为。
-
float: left的img后面紧跟p，p内的文字会绕，但整个p盒子的上边界可能仍与图片顶部对齐（取决于margin-top和vertical-align） - 如果文字被“切掉开头”，大概率是
line-height太小或图片未设vertical-align: top，导致行盒高度被基线拉偏 -
display: inline-block或display: inline元素也会被当作文字处理，同样绕浮；但div、h1等块级元素默认不绕，只会在浮动元素下方开始渲染
为什么非浮动块级元素的背景会被“盖住”
看起来像“文字没被盖、但背景被盖了”，其实是两个不同层级的问题：background-color 和 border 属于块级盒模型（block formatting context），而文字属于行内格式化上下文（IFC）。当父容器没形成 BFC，又没被浮动元素撑高时，非浮动 div 的计算高度常为 0px，它的背景就从顶部开始画，视觉上叠在浮动元素背后。
这不是 z-index 控制的层叠，而是布局断裂造成的错位。用开发者工具检查该元素的 computed height，基本就能确认是不是塌陷问题。
立即学习“前端免费学习笔记（深入）”；
- 给父容器加
overflow: hidden或display: flow-root可触发 BFC，让父容器包含浮动、高度正常，背景也就回到文字下方该在的位置 -
clear: both加在非浮动块级元素自身上才有效，加在浮动元素上或父容器上都没用 - 若该块级元素设了负
margin-top，clear可能被抵消，看起来像失效
想让文字不绕浮？别硬清，换容器上下文
很多人想“清除浮动影响”来阻止环绕，其实方向反了：环绕是 float 的本职工作，真正该做的是隔离容器。与其用 clear 往下推文字，不如让文字容器自己拒绝参与环绕。
overflow: hidden 能立刻生效，但副作用明显：所有溢出内容（比如 transform 拉出的提示框、下拉菜单）都会被裁剪。更干净的做法是用 display: flow-root ——它专为解决此类问题而生，触发 BFC 且无裁剪风险。
-
display: flow-root是现代标准解法，兼容性已覆盖 Chrome 64+、Firefox 59+、Safari 15.4+，旧版需 fallback - 若必须支持 IE，可用伪元素清除：
::after { content: ""; display: table; clear: both; }，但只是兜底，不改变 float 的排版本质 - 不要给文字容器本身设
float，否则它也脱离流，后续内容又得处理新塌陷
现在还该用 float 做布局吗
不该。多列、对齐、响应式栅格这些需求，display: flex 和 display: grid 天然不脱离文档流，父容器高度自动包含子项，没有塌陷、没有环绕干扰、没有清除逻辑。你花在调试 clear 和 overflow 上的时间，早够重写成 Flex 了。
真正需要 float 的场景只剩两个：一是图文混排（比如新闻正文里图片左浮、文字右绕），二是极老环境兼容（IE8 及以下）。其他情况用 float，等于主动给自己埋 layout debt。
哪怕你用了 flow-root 或伪元素“清浮动”，也改不了 float 的语义本质——它始终是排版指令，不是布局工具。这点一旦忽略，就容易把问题归咎于“清除没做好”，而不是“用错了工具”。
