旧版firefox下浮动错位主因是漏写display: block和box-sizing: border-box，且clear: both易被布局上下文拦截；clearfix伪元素不兼容ie6/7，需用*zoom: 1等降级方案。
旧版 Firefox（
为什么 float 在旧版 Firefox 里“突然掉行”？
这不是 bug，是规范实现差异。Firefox 会把 inline 元素（如文字、<img>）的 line-height 和基线位置纳入浮动容器可用宽度判断，导致它比 Chrome 更早判定“放不下”，触发换行。
- 多个
float: left元素总宽接近 100% 时，Firefox 更容易因 sub-pixel 四舍五入误差（比如33.33% × 3 = 99.99%）拒绝同行 -
<img>或<span></span>没设vertical-align，Firefox 按 baseline 对齐并预留额外空间，使实际占用宽度 > 声称宽度 - 父容器含
white-space: normal文本节点时，Firefox 会把文本行高参与浮动边界计算，Chrome 则常忽略
必须显式写的两个基础声明
Firefox 从没给 float 加过 -moz- 前缀——你查不到 -moz-float。但以下两项漏写，浮动几乎必然错位：
-
display: block：必须加在浮动元素上。旧版 Firefox 对<span></span>或<a></a>直接加float时，可能不触发块化，导致对齐漂移 -
box-sizing: border-box：旧版 Firefox 对content-box下的padding+border溢出容忍度极低；width: 50%+padding: 5px就足以让第二项掉行
clear: both 失效的真实原因
不是 clear 不起作用，而是它被“看不见的布局上下文”拦截了：
- 父容器用了
position: relative但没设z-index，而清除元素又在另一个 stacking context 里，Firefox 会错误判定清除范围 - 清除元素自身有
margin-top，且该值小于浮动元素的margin-bottom，Firefox 会合并这两个 margin，导致清除“没顶到头” - 清除元素是
<div>，但父容器设了 <code>font-size: 0（为消除 inline 间隙），而该<div> 没重置 <code>font-size，Firefox 会将其line-height压缩为 0，清除失效别用 clearfix 的现代写法
旧版 Firefox（尤其是 IE6/7 兼容场景）不支持
::after伪元素，所以主流.clearfix::after { content: ""; display: table; clear: both; }会失效。- 兼容方案：
.clearfix { *zoom: 1; }（触发 hasLayout） +.clearfix:before, .clearfix:after { display: table; content: ""; }+.clearfix:after { clear: both; } - 更稳妥 fallback：
overflow: hidden或overflow: auto（注意可能意外裁剪或滚动条） - 避免用
clear: both放在浮动元素内部——它只对后续兄弟元素生效，旧版 Firefox 对嵌套清除解析更脆弱
真正麻烦的不是写对几行 CSS，而是旧版 Firefox 会把多个微小偏差（
box-sizing、vertical-align、line-height、sub-pixel 渲染）叠加放大。哪怕你 fix 了掉行，下个页面可能因字体渲染宽度差 1px 又崩了——得在 DevTools 的 Computed 面板里逐层核对每个浮动项的最终 width、margin、line-height 值。 - 兼容方案：
