inline元素的margin-left/margin-right能生效，因参与IFC水平布局并计入行内盒总宽以推开相邻内容；而margin-top/margin-bottom被规范忽略，不参与行框高度计算，属标准行为非bug。
display:inline 元素的 margin-left/margin-right 为什么能生效
因为 inline 元素仍参与行内格式化上下文（IFC）的水平布局，左右 margin 会被计算进「行内盒」的总宽度，用于推开相邻的行内内容。规范明确允许它影响水平间距，这和 vertical-align、line-height 共同决定元素在行框中的位置。
典型表现是：<span> 加 margin-left: 10px 后，左边文字被推开；多个 <a> 并排时用 margin-right 分隔，也完全可用。
但注意：这种“有效”不等于“绝对可靠”——它依赖父容器的 line-height、字体大小、甚至是否启用 text-rendering: optimizeLegibility，某些极端缩放或字体组合下，视觉间距可能被压缩或遮盖。
为什么 margin-top/margin-bottom 在 display:inline 下被忽略
CSS 规范要求 inline 元素不参与行框（line box）的高度计算，所以 margin-top 和 margin-bottom 虽被解析，但直接丢弃，不参与布局。这不是浏览器 bug，而是所有标准模式浏览器（Chrome、Firefox、Safari、Edge）统一行为。
立即学习“前端免费学习笔记（深入）”；
常见误判场景：
- 给
<strong>设margin-bottom: 20px，下面段落没下移 → 实际是 margin 被忽略，行高未变 - Computed 面板里该值显示为 strike-through（划掉）→ 表明已解析但未应用
- 加了
padding-top却看不见效果 → padding 上下虽渲染，但被 line box 的基线对齐“吞掉”，不撑开行高
inline 元素的左右 margin 容易踩的坑
左右 margin 看似安全，但在实际项目中常因以下原因失效或错位：
- 父容器设置了
white-space: nowrap或text-overflow: ellipsis，导致行内元素被截断，margin 被裁剪不可见 - 相邻元素是
inline-block或替换元素（如<img>），它们的vertical-align值不同，造成基线错位，看起来像 margin 没对齐 - 使用了 CSS-in-JS 工具（如 Emotion、Styled Components），某些版本会自动 strip 掉 inline 元素的 margin 声明（尤其当检测到 display: inline 时）
- HTML 中存在不可见字符（如零宽空格、BOM），干扰了行内盒的边界计算，使 margin 表现不稳定
什么时候该放弃 inline + margin，换别的方案
当你需要稳定、可预测、跨浏览器一致的水平间距时，display: inline + margin-left/right 就不是首选：
- 要等距分布多个链接或标签 → 改用
display: flex+gap，无 HTML 空白干扰 - 需微调单个字符/图标间距 → 优先用
letter-spacing或word-spacing，更语义且不触发重排 - 想让行内元素拥有完整盒模型控制权（比如加边框、背景、hover 扩展）→ 直接设
display: inline-block，再配vertical-align: middle和font-size: 0消除间隙 - 涉及响应式缩放或 rem 布局 →
margin值可能被小数像素四舍五入，出现 1px 抖动，此时用transform: translateX()更稳定
真正难处理的不是 margin 生效与否，而是你改完之后，那个 <span class="tag"> 在 Safari iOS 16 和 Chrome Android 15 里，左右留白差了 0.3px —— 这种细微差异，只有真机调试才能暴露。
