ie6双倍边距仅在quirks模式下触发，根本原因是无doctype时ie6错误重复计算浮动元素的横向margin；标准模式下该bug不存在，display:inline非修复手段而是历史误用，现代项目应删除。
IE6双倍边距只在Quirks模式下触发
根本原因不是float本身有问题，而是IE6在怪异模式（Quirks Mode）下解析浮动元素时，错误地将margin-left或margin-right重复计算了一次。只要HTML顶部有，IE6就走标准模式，这个bug压根不会出现。
真正触发条件是“float + 横向margin + 无DOCTYPE”三者同时存在
单独写float: left不会出问题；单独写margin-left: 10px也不会；只有当页面没声明DOCTYPE、又用了浮动、又设了同方向margin时，IE6才误入那条错误的渲染路径。
- 第一个浮动子元素相对父容器触发bug，后续兄弟元素不触发（因为它们相对前一个浮动元素定位）
-
display: inline不是修复手段，而是早期误传——它只是让IE6切换到另一条（恰好没bug的）渲染分支，但会破坏vertical-align、干扰flex/grid布局 - 现代项目基本已弃用IE6，删掉所有
display: inline对浮动元素的滥用，反而更安全
为什么很多人以为display:inline能“修”这个bug
因为IE6在Quirks模式下，浮动元素默认参与行内格式化上下文（IFC）计算，而display: inline显式强化了这条路径——结果阴差阳错绕过了双倍margin的错误逻辑。但这纯属巧合，不是设计行为。
- 它对Chrome/Firefox/Edge/IE8+完全无效，也不被任何CSS规范支持
- 加在父元素或伪类上没用，必须直接作用于那个浮动元素自身
- 如果已有
display: block，得用display: block !important覆盖，否则IE6仍按默认逻辑走
现在还该不该处理这个bug
除非你正在维护一个明确要求支持IE6的遗留系统（比如某些政务内网），否则不用管。绝大多数项目早已强制标准模式，构建工具也自动剔除*display这类hack。
- 检查代码里有没有裸写的
display: inline跟在float后面——大概率是2006年的历史包袱，删了更干净 - 如果真要兼容，优先用
zoom: 1触发hasLayout，比display: inline副作用小得多 - 最彻底的解法是换布局方式：用
padding代替margin，或者套一层非浮动wrapper控制间距
真正难的不是怎么写一行CSS让IE6不double margin，而是怎么判断哪一行display: inline还在悄悄撑开侧边栏——尤其当它没注释、没上下文、又卡在关键节点上时。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
