Firefox中float元素“突然掉行”并非bug，而是其严格按CSS2.1规范将inline内容的line-height、基线及sub-pixel四舍五入（如33.333%×3=99.999%→99px）纳入宽度计算，导致比Chrome更早换行。
浮动在 Chrome 和 Firefox 中表现不一致，不是浏览器 bug，而是两者对 min-width、box-sizing、vertical-align 和亚像素四舍五入的处理逻辑不同——尤其当总宽度逼近 100% 时，Firefox 更早换行，Chrome 更“宽容”。核心解法不是修浮动本身，而是切断所有隐式干扰源。
为什么 float: left 在 Firefox 里突然掉行？
Firefox 会把内联内容（比如文字、<img>）的 line-height 和基线位置纳入浮动容器的可用宽度判断；Chrome 常忽略这部分。结果就是同一段 HTML，在 Firefox 中算出的“已用宽度”比 Chrome 多出 1–2px，临界点直接触发换行。
-
width: 33.333%× 3 = 99.999%，Firefox 四舍五入为 99px，Chrome 算成 100px -
<img>没设vertical-align，Firefox 按 baseline 预留额外空间，实际占宽 > 声称宽度 - 父容器含文本节点且
white-space: normal，Firefox 把文本行高参与边界计算
必须写在最前面的三条重置规则
*、*::before、*::after 的 box-sizing: border-box 必须放在所有 CSS 文件顶部，否则被 normalize.css 或第三方样式覆盖后，Computed 面板里能看到它被划掉。
-
*, *::before, *::after { box-sizing: border-box; }—— 伪元素也要参与尺寸计算，否则::after清除浮动时高度异常 -
body { margin: 0; line-height: 1.5; font-size: 16px; }—— 统一基线和缩放基准，避免 em 单位浮动项宽度浮动 -
img, video, canvas, svg { vertical-align: top; }—— 解决图片浮动后底部空白，IE 和 Safari 对此处理尤其不一致
clear: both 在 Firefox 里失效的真实原因
不是 clear 不起作用，而是它被“看不见的布局上下文”拦截了：父容器用了 position: relative 但没设 z-index，而清除元素又在另一个 stacking context 里，Firefox 会错误判定清除范围。
立即学习“前端免费学习笔记（深入）”；
- 清除元素自身有
margin-top，且该值小于浮动元素的margin-bottom，Firefox 会合并这两个 margin - 清除元素是
<div>，但父容器设了font-size: 0（为消除 inline 间隙），而该<div>没重置font-size，Firefox 将其line-height压缩为 0，清除失效 - 旧版 Firefox 不支持
::after，推荐兼容写法：.clearfix { *zoom: 1; }+.clearfix:before, .clearfix:after { display: table; content: ""; }+.clearfix:after { clear: both; }
真正麻烦的不是写对几行 CSS
而是浮动布局中每一层嵌套都可能引入新的尺寸变量——从伪元素到 SVG 图标，只要有一个没被 border-box 覆盖，就可能成为压垮一致性的最后一像素。哪怕你重置了全部，也得打开 DevTools → Computed → 点开 box-sizing，确认“来源”是不是你预期的那条规则；第三方脚本动态注入的 <style> 标签，常常无声覆盖你的重置。
