inline-block元素间间隙源于HTML换行/空格解析的空白文本节点，非 导致；设父元素font-size:0可消除间隙，但子元素须重置font-size；flex布局下无需 ，应改用gap控制间距。
inline-block 元素间用 会放大间隙吗
不会。 是不可换行空格，它只在文本流中起作用；而 inline-block 元素之间的间隙来自 HTML 源码里的换行符或空格字符（被解析为一个空白文本节点），不是 导致的。你手动插入 ，只会多出一个“可见空格”，宽度由当前 font-size 决定，但不会“放大”原本那约 4px 的间隙——它只是叠加了一个新空格。
常见错误现象：A B 中的空格被当成空白节点 → 出现间隙；误以为加 能控制这个间隙，结果写成 A B，反而多出一个额外空格，更难对齐。
- 源码换行 / 空格 → 解析为一个空白文本节点 → 渲染为约
font-size × 0.25宽的间隙（典型值 4px） -
font-size - 两者叠加，间隙变大且不可预测，尤其在响应式中 font-size 动态变化时
为什么给父容器设 font-size: 0 能消除 inline-block 间隙
因为那个间隙本质是空白文本节点，而文本节点的宽度取决于其继承的 font-size。设父元素 font-size: 0 后，空白节点没了字号，就没了渲染宽度；再单独给子元素设置 font-size，只影响文字本身，不复活间隙。
注意：必须同时重置子元素字体，否则文字会消失或极小；图片、图标类 inline-block 元素也适用，但需确认它们不依赖父级 line-height 或垂直对齐逻辑。
- 父容器加
font-size: 0，子元素必须显式声明font-size（哪怕只是16px） - 若子元素含
vertical-align，可能因line-height: 0连带失效，建议补一句line-height: normal - 该法对 SEO 和可访问性无害，DOM 结构完全保留，比删换行更易维护
flex 替代 inline-block 后， 还需要吗
不需要，而且加了反而坏事。display: flex 的容器天然忽略子元素间的源码空白， 会被当作一个独立的文本子节点渲染——可能出现在第一个或最后一个元素旁边，破坏对齐，还增加不必要的 DOM 节点。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
正确做法是统一用 gap 控制间距，它不依赖字体、不触发文本渲染逻辑、支持响应式单位（如 gap: 1rem），且能分别控制行列（gap: 8px 12px）。
- 旧写法：
- 新写法：
.btns { display: flex; gap: 12px; }→ 干净、可控、无副作用 - IE 不支持
gap？那就用margin-right配合:not(:last-child)，别回头用
white-space: pre-wrap 里混用 会怎样
会冲突。white-space: pre-wrap 保留源码中的空格和换行，但 是一个特殊字符实体，浏览器仍按“不可换行空格”处理——它不会被折叠，但也不会像普通空格那样参与自动换行对齐，容易造成视觉错位，尤其在中英文混排时。
真实场景中，比如日志预览、代码注释、带缩进的说明文本，应优先靠 CSS 的 text-indent、padding-left 或 tab-size 控制缩进，而不是塞一堆 。
-
pre-wrap容器里仍是“一个字符”，宽度固定，不随上下文缩放 - 连续多个
- 真正要对齐中文标题或表格内字段，用
letter-spacing或text-align: justify更稳妥
最易被忽略的一点：空格问题从来不是“怎么多打几个空格”，而是“哪个层级该由谁控制”。文本内空格用 或 white-space，布局间隙只认 margin、padding、gap —— 混用就等于让 CSS 和 HTML 实体抢着管同一件事，结果谁也管不好。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
