inline-block间隙不是bug，而是HTML解析器将换行符、空格等视为空格字符（U+0020）在行内格式化上下文中渲染所致，宽度≈父容器font-size的0.25em；消除方案中font-size:0需作用于直接父容器并重设子元素字号，现代项目更推荐flex+gap。
inline-block间隙不是bug，是HTML解析规则的正常表现
这个间隙不是你漏写了margin或padding，也不是浏览器bug。它是HTML解析器把标签之间的换行符、空格、制表符当作一个“空格字符”（U+0020）来处理的结果——属于行内格式化上下文（IFC）的标准行为。
只要两个display: inline-block元素在源码里不在同一行，就会生成这个间隙。它的宽度≈父容器font-size的0.25em（比如font-size: 16px时约4px），且会随字号缩放，不是固定像素值。
font-size: 0方案必须严格满足三个条件才有效
这是兼容性最好（IE8+）、语义最干净的解法，但失效往往是因为没踩准关键点：
-
font-size: 0必须设在**直接包裹 inline-block 子项的父容器**上；套多一层div却没设，无效 - 所有子元素会继承
font-size: 0，所以每个含文本的子元素必须显式声明font-size（如16px或1rem），不能只写inherit - 若子元素用了
em单位（如line-height: 1.5或width: 20em），计算结果为0，需改用无单位数值（line-height: 1.5）或px/rem
<img>虽无文本，旧版 Safari 仍可能异常，建议统一加font-size: 16px。
立即学习“前端免费学习笔记（深入）”；
现代项目优先用 display: flex + gap 替代 inline-block
如果你最低支持 Chrome 89+、Firefox 63+、iOS Safari 14.1+，display: flex是更可靠的选择：
-
gap属性直接控制间距，不依赖字体大小，响应式友好 - 无需担心继承污染、单位计算失效、Safari渲染差异等问题
- 对
flex-wrap、对齐、顺序等控制能力远超inline-block - 回退可用
margin-right: 8px+:not(:last-child)，比负margin稳定得多
哪些“看起来能用”的方法实际埋了坑
这些做法短期见效，长期维护成本高，且容易引发新问题：
- 手删HTML换行和空格：牺牲可读性，格式化工具一运行就还原
- 用
<!-- -->隔开：代码臃肿，协作时极易遗漏或误删 - 负
margin（如margin-left: -4px）：缝隙宽度随font-size变化，媒体查询里改字号就得同步调；Chrome/Safari 渲染差异还可能导致1px偏差 - 对
<body>或全局容器设font-size: 0：极易遗漏恢复，整页文字消失
真正容易被忽略的是：当 legacy 代码还没重构完，有人一边用font-size: 0，一边又加transform: scale(0.99)或letter-spacing: -0.31em补丁——这些补丁本身就会触发新的渲染异常，而且屏幕阅读器仍按原始 HTML 结构解析。
