inline-block空隙更难预测，因其源于HTML解析器将换行/空格渲染为不可见文本节点（约4px），不响应margin/padding且开发者工具不可见；而浮动清除问题有明确触发条件和标准方案，如clear:both或display:flow-root。
inline-block 的空隙比浮动的清除更难预测
因为 inline-block 间隙是 HTML 解析器把换行符和空格当成文本节点渲染的结果，不是 CSS 层面的 margin 或 padding，所以它不响应 margin、padding 调整，也不受 box-sizing 影响。开发者工具里甚至看不到这个“间隙”对应的盒模型——它只是个看不见的字符宽度（通常约 4px）。而浮动的清除问题至少有明确触发条件：父容器高度塌陷、后续元素错位、基线对齐留白等，都能在 computed 样式或盒模型中定位。
清除浮动有标准模式，处理 inline-block 空隙却要权衡副作用
常见清除浮动方式如 ::after 伪元素 + clear: both 或 display: flow-root，语义清晰、行为稳定、不影响子元素样式。但 inline-block 空隙的解法都带 trade-off：
-
font-size: 0在父容器上生效快，但会继承影响内部input、button、select等表单控件的默认字号，必须逐个重置 - HTML 注释法（
<!-- -->）绕过 CSS，但让模板难以阅读，Git diff 易混乱，组件复用时容易漏掉 -
margin-left: -4px依赖像素值，缩放、字体放大、DPR 变化时失效，且对最后一个子项需额外处理
维护成本差异集中在“改一处，崩一片”的风险上
浮动布局一旦写死，改一个子项的 width 或 height，常连带要调 clear 位置、重算父容器 overflow、检查文字环绕是否错乱；inline-block 表面温和，但加个图标、换行、插个注释，就可能让整排错位——尤其在多人协作或 CMS 动态插入内容时，空隙会从“看不见”变成“不可控”。
真正降低维护成本的，不是选哪个旧方案，而是尽早用 display: flex 替代两者：gap 控制间距、flex-wrap 处理折行、无需清除、无空隙、不塌陷——这些不是“高级功能”，而是现代布局的默认行为。老项目迁移时，优先封住浮动/inline-block 的作用域（比如只用于按钮组、标签云这类小范围组件），别让它扩散到主容器层级。
立即学习“前端免费学习笔记（深入）”；
