浮动元素脱离文档流，不参与父容器高度计算但影响文本环绕和块级元素布局；父容器高度常为0，需通过BFC或clear清除浮动来修复。
浮动元素脱离文档流，但会影响其他元素的布局
浮动元素（float: left 或 float: right）会从**正常文档流中被移除**，不再占据原本的块级空间——也就是说，后续的普通流块元素（如 <p></p>、<div>）会“无视”它原来的位置，向上或向侧“塌陷”填充。但这不等于它完全“消失”：它仍参与行内布局计算，且会撑开父容器（如果父容器没清除浮动，高度可能坍缩）。
<h3>为什么父容器经常高度为 0？</h3>
<p>因为浮动子元素已脱离文档流，父容器在计算自身高度时，不会把它们的高度纳入考量。常见现象是：<pre class="brush:php;toolbar:false;"><div class="parent">
<div class="child" style="float: left; height: 100px;"></div>
</div></pre>此时 <code>.parent 的 height 计算结果为 0（除非有其他非浮动内容撑高）。
- 这不是 bug，是 CSS 规范对浮动的明确定义
- 父容器“看不见”浮动子元素的高度，但能感知其对行盒（line box）的影响（比如文字环绕）
- 解决方式不是让浮动元素“回到流中”，而是用清除浮动（
clear）或 BFC 触发（如overflow: hidden、display: flow-root）来重绘包含块边界
浮动元素是否还影响其他元素的位置？
会，而且影响方式很具体：
- 后续**块级元素**会无视浮动元素垂直位置，从顶部开始布局（但文字内容会绕开浮动元素）
- 后续**行内元素和文本**会感知浮动框边界，自动形成环绕效果（这是浮动最初的设计目的）
- 如果给后续块元素设置
clear: both，它会强制下移到浮动元素下方，避开所有浮动区域 - 浮动元素自身的
margin、padding、border仍生效，但这些盒模型尺寸不参与父容器高度计算（除非触发 BFC）
现代开发中该不该依赖浮动做布局？
不推荐。浮动本质是为图文混排设计的，不是布局工具：
-
float在 Flexbox 和 Grid 普及后已退居次要地位 - 清除浮动逻辑易出错（比如漏写
clearfix、嵌套清除失效） - 响应式场景下难以控制断点行为，
float无内置对齐/分布能力 - 若必须兼容老浏览器（IE8–），才考虑用
float+:after伪元素clear；否则优先用display: flow-root包裹浮动子项，或直接切到display: flex
真正容易被忽略的是：浮动元素的“存在感”是分层的——它对父容器高度“隐身”，对同行文本“显形”，对后续块级流“半透明”。理解这三层，比死记“是否占空间”更有实际调试价值。
立即学习“前端免费学习笔记（深入）”；
