能替代但不能无脑替换；必须成对修改、提供fallback、且仅在方向可变场景（如多语言组件库、显式direction/writing-mode设置）中才值得使用，否则易导致视觉偏差或兼容性问题。
能替代，但不能无脑替换；必须成对改、带 fallback、且只在方向可变的场景里才值得动。
什么时候该用 margin-inline 而不是 margin-left/margin-right
只在以下三类场景中它才有实际价值：
- 组件需同时支持
dir="ltr"和dir="rtl"（如按钮组、表单控件水平间距） - 父容器显式设置了
direction: rtl或writing-mode: vertical-rl，且你希望边距随流向自动映射 - 正在封装 UI 组件库，目标是“写一次，多语言复用”，而非临时修一个页面
纯装饰性偏移（比如图标微调）、绝对定位元素、或已用 flex-direction: row-reverse 显式翻转的容器，margin-inline 不仅没优势，反而增加理解成本。
为什么直接替换会出视觉偏差
margin-inline: 1rem 2rem 在 LTR 下等价于 margin-left: 1rem; margin-right: 2rem，但在 RTL 下变成 margin-left: 2rem; margin-right: 1rem——它是方向感知的。而传统写法是硬编码物理位置，不随 dir 变化。
立即学习“前端免费学习笔记（深入）”；
常见错误包括：
- 只改
margin-right: 8px→margin-inline-end: 8px，却漏掉同级的margin-left: 16px→ 必须同步改为margin-inline-start: 16px，否则 RTL 下左右不对称 - 在
position: absolute元素上设margin-inline: 20px：它不影响left/right偏移，只参与流式布局计算，视觉上几乎无感 - 误以为
margin-inline-start总是“左边”：若父级设了writing-mode: vertical-lr，它的物理位置其实是底部
旧浏览器怎么 fallback 才不崩
IE11、Edge 17 及更早、Android WebView 4.4、Safari ≤14 都不支持 margin-inline，且静默丢弃整条声明——不会报错，但边距消失。
唯一可靠方案是顺序写：
button {
margin-left: 1rem;
margin-right: 1rem;
margin-inline: 1rem; /* 仅新浏览器生效，覆盖上面两行 */
}注意：margin-inline: 1rem 是 margin-inline-start: 1rem; margin-inline-end: 1rem 的简写；如果上下文是 direction: rtl，fallback 应该是 margin-right: 1rem 而非 margin-left，但 CSS 无法自动判断，此时需 JS 检测后注入，或构建时预编译。
为什么加了 margin-inline 却没反应
最常被忽略的是上下文依赖：
- 没显式设置
direction或writing-mode，浏览器用默认值（horizontal-tb+ltr），此时它确实等效于左右，但一换语言就失效 - 父级设了
writing-mode: vertical-rl，margin-inline-start就指向顶部，不是左右 - 元素是
display: inline，margin-inline: auto不会居中；必须是块级 + 有明确宽度 -
overflow: hidden或contain: layout会截断 margin 的视觉表现，但 computed 值仍存在
排查时直接看开发者工具的 Computed 面板，确认 margin-inline-start 的最终解析值是否符合当前 direction 和 writing-mode 下的预期物理位置。
