浮动元素的定位起点是行框盒子的顶部，而非父容器顶部；它先参与行框构建，再抬升至行框顶部对齐，因此受行框高度（由内联元素基线等决定）影响，导致常见贴顶错位现象。
浮动元素的定位起点是行框盒子的顶部
浮动元素不会从父容器顶部开始“漂”，而是先参与行框（line box）构建，再从中“抬升”到行框顶部对齐。这个细节决定了它和普通流内联内容（比如文字、inline元素）的初始关系。
常见错误现象：给一个<span></span>加float: left，却发现它没贴着父<div>顶边，而是卡在文字基线附近——这就是因为它先被放进当前行框，再浮动上去，而行框高度由内部最高内联元素（比如带<code>vertical-align: baseline的文字）决定。
- 使用场景：图文混排时，图片左浮动但文字底部不齐，本质是行框被文本撑高了
- 解决方法：给浮动元素设
vertical-align: top无效（浮动后该属性失效），真正有效的是控制行框本身——给父容器设font-size: 0或line-height: 0来压缩行框高度，再单独恢复子元素字号 - 注意：
clear只影响后续块级元素的起始位置，不影响当前浮动元素在行框中的“出生点”
边框和内边距会改变浮动元素的“占位宽度”，但不改变行框参与逻辑
浮动元素脱离文档流后，它的尺寸仍按盒模型计算，border和padding会真实增加其水平占用空间，进而影响是否换行、是否挤出父容器——但它是否参与当前行框，只取决于它是否在普通流中生成时位于该行。
例如两个float: left的<div>，一个有<code>border: 3px solid，另一个没有，即使内容宽度相同，前者更可能触发换行；但它们都已脱离行框，不再影响后续文字的行高或断行位置。
立即学习“前端免费学习笔记（深入）”；
- 容易踩的坑：用
box-sizing: content-box（默认）写多列浮动布局时，忘记边框会让总宽“悄悄超标”，调试时只盯着width值看，漏掉2px × border的误差 - 实操建议：全局加
* { box-sizing: border-box; }，让width包含border和padding，浮动列宽度计算回归直觉 - 兼容性提醒：
border-box在 IE8+ 完全支持，无需降级处理
父容器高度塌陷不是“bug”，而是浮动脱离行框和块流的自然结果
父容器没有高度，并非因为“忘了清除浮动”，而是因为浮动元素既不参与块格式化上下文（BFC）的高度计算，也不参与行框构建——它像一张透明胶片盖在上面，下面的流完全感知不到它。
典型表现：<div class="wrap"><div class="float-box"></div></div>中，.wrap高度为0，背景色不显示，margin也无效。
- 为什么
clearfix有效？本质是通过::after伪元素插入一个display: table或clear: both的块级内容，强制在浮动下方生成一个新块，从而撑开父容器 - 现代替代方案：
display: flow-root是最轻量解法，它让父容器创建新的BFC，自动包含浮动子元素高度，且无额外DOM或伪元素 - 别用
overflow: hidden硬撑——它虽能触发BFC，但会意外裁剪position: absolute子元素或阴影
浮动与行内元素共存时，行框会为浮动“让出空间”，但不会重排已渲染文字
当一段文字旁边有左浮动元素时，行框会缩短，文字自动绕行；但这个“绕行”不是实时重绘，而是浏览器在构建行框阶段就预留了浮动占据的空间。一旦行框形成，后续修改浮动元素width或margin，文字不会回流重排——除非触发重排（如窗口缩放、显式reflow）。
- 性能影响：频繁修改浮动元素尺寸会引发连续重排，比Flex/Grid布局成本高得多
- 调试技巧：用开发者工具选中浮动元素，勾选“Show layout shifts”，可直观看到哪些行框因浮动变化而被迫重建
- 关键提醒：浮动绕行只发生在**同一BFC内**；跨BFC（如父容器设了
overflow: auto）时，行框根本看不到浮动，文字会直接从浮动下方穿过
事情说清了就结束。行框盒子不是浮动的“容器”，而是它出发前的最后一站；所有视觉错位，几乎都能回溯到这一句。
