旧版 firefox（
旧版 Firefox（Firefox ，尤其 <code>Firefox 52 ESR 及更早）对浮动布局的显示异常，**基本不是因为私有属性缺失，而是它严格遵循早期 CSS2.1 规范中关于“浮动边界计算”和“行框重排”的定义，与 Chrome/Safari 的宽松实现形成差异**。所谓“检查私有属性兼容”是个误导方向——你找不到 -moz-float 这种东西，Firefox 从没为 float 加过前缀。
Firefox 52–59 中浮动换行错位的真实原因
当多个 float: left 元素并排、总宽度接近父容器时，Firefox 会因以下两点提前触发换行：
- 对
white-space: normal下的文本节点，计算行框高度时把内联元素的line-height和基线位置纳入浮动边界判断，导致可用宽度被低估 - 在子元素含
inline-block或img时，若未显式设vertical-align: top，Firefox 会按 baseline 对齐并预留额外空间，使浮动容器实际占用宽度 > 声称宽度 - 对百分比宽度的累积误差更敏感：比如
width: 33.33%× 3，在 sub-pixel 渲染阶段 Firefox 四舍五入策略不同，可能算出99.99%并拒绝最后一项同行
别查 -moz- 前缀，先确认 display 和 box-sizing
Firefox 从未给 float、clear 或 overflow 加私有前缀。但以下两个基础声明在旧版 Firefox 中极易被忽略，却直接决定浮动是否“看起来正常”：
-
display: block必须显式写在浮动元素上——虽然规范允许省略，但旧版 Firefox 在解析inline元素（如<span></span>）加float时，可能不触发块化，导致对齐错乱 -
box-sizing: border-box必须统一应用——旧版 Firefox 对content-box下的padding+border溢出容忍度更低，一个width: 50%+padding: 5px就足以让第二项掉行
clear: both 在 Firefox 中失效的典型场景
不是 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，造成清除高度塌陷真正该检查的“兼容性开关”是 @supports
旧版 Firefox 支持
@supports，但仅限于简单语法。如果你用@supports (float: left) and (display: flow-root)做降级，Firefox 57+ 会直接跳过整段规则——因为它不支持flow-root，所以整个条件为假。这不是 bug，是规范行为。更安全的写法是分层检测：
@supports (display: flow-root) { .parent { display: flow-root; } } @supports not (display: flow-root) and (float: left) { .parent::after { content: ""; display: table; clear: both; } }注意：
@supports not (display: flex)在 Firefox 52 中返回true，但display: flex其实已部分支持——这种“伪不支持”容易让你误删本可工作的代码。最容易被忽略的是：Firefox 的开发者工具「Computed」面板里显示的
clear值为both，不代表它真参与了布局计算。必须打开「Layout」→「Box Model」，看清除元素的 margin 是否被实际撑开——否则你调的只是个幻影。
