inline-block间隙宽度=父容器font-size×0.25–0.3，如16px时约4px；必须在直接父容器设font-size:0并重置子元素字号，或改用flex/grid布局。
inline-block 间隙的像素值到底由什么决定
这个“约 4px”的间隙不是固定值，而是由父容器的 font-size 直接驱动的。浏览器把换行/空格解析为一个“空格字符”，而该字符的宽度 = 当前 font-size × 当前字体的空格比例（通常在 0.25–0.3 左右）。所以：font-size: 16px 时常见 ~4px，font-size: 20px 时可能变成 ~5px，font-size: 0 则直接归零。
容易踩的坑：
- 只给子元素设
font-size: 0没用——必须作用在**父容器**上，否则空格仍按父级字号渲染 - 设了
font-size: 0后，子元素里的文字会消失，得单独重置：比如div > span { font-size: 14px; } - 用注释隔断（
<div></div> <!-- --><div></div>）虽有效，但源码可读性差，协作时易被误删
flex 或 grid 替代 inline-block 的真实代价
改用 display: flex 或 display: grid 确实能彻底绕过空格问题，但要注意兼容性断层：
-
flex在 IE10+ 支持基本布局，但 IE10/11 对flex-wrap、align-content等有严重 bug，不能无脑迁移 -
grid在 IE 中完全不可用（仅支持 -ms-grid 且语法不兼容），若需支持 IE，必须降级方案 - 两者都会改变文档流行为：比如
flex容器内子项默认 stretch，可能撑高卡片高度；grid需显式定义轨道，小改动易引发整体重排
为什么不要依赖「删 HTML 空格」作为长期方案
手动删除源码中所有换行和缩进看似一劳永逸，但实际维护成本极高：
立即学习“前端免费学习笔记（深入）”；
- HTML 压缩工具（如 html-minifier）确实能干这事，但开发阶段保留格式对调试至关重要
- 多人协作时，IDE 自动格式化（Prettier）、Git 合并冲突、模板引擎（如 Handlebars、Vue SFC）插值都会重新引入空白
- 一旦混用 SSR + CSR，服务端渲染出紧凑 HTML，客户端 hydrate 时却因 JS 动态插入带换行的节点，间隙可能闪现
mso- 前缀与 Word 导出场景下的空格表现
导出 HTML 到 Word 时，inline-block 间隙不仅没消失，还可能被 Office 渲染引擎放大或错位，因为 Word 使用自己的排版引擎（MSO），对 CSS 解析极简：
-
font-size: 0在 Word 中常被忽略，间隙照常出现 -
display: flex完全不识别，回退为块级堆叠，破坏原有布局 - 唯一可靠路径是改用
table布局（display: table-cell）+mso-table-lspace: 0pt; mso-table-rspace: 0pt;，这是 Outlook/Word 兼容性事实标准
空格间隙的本质是文本渲染逻辑，不是 bug，也不是样式缺陷。它会在你切换视图模式、导出到不同宿主、甚至升级字体时悄悄变化——最稳的解法从来不是“消灭空格”，而是让布局不再依赖空格的存在。
