margin-inline在旧版双方向排版中失效，根本原因是浏览器早期实现未正确处理direction与unicode-bidi组合，导致margin-inline-start在dir="rtl"下仍映射到左侧而非右侧；firefox 70–89和safari 13–15.6表现明显，需用@supports+物理属性兜底并显式控制unicode-bidi。
直接说结论：margin-inline 在旧版双方向（bidi）排版中失效，根本原因是浏览器对逻辑属性的早期实现未正确处理 direction 与 unicode-bidi 的组合影响，尤其在 Firefox 70–89 和 Safari 13–15.6 中表现明显。
为什么 margin-inline 在 dir="rtl" 下不按预期生效？
问题核心在于：当父容器设为 dir="rtl"，但子元素未显式继承或重置 unicode-bidi，部分旧引擎会忽略 margin-inline-start 对应的物理方向映射，导致它仍作用于左侧（而非右侧）。这不是 CSS 规范问题，而是渲染层对逻辑轴计算的偏差。
-
margin-inline-start应该始终对应当前书写方向的“起始侧”，但在 Safari 14.1 中，若父级有dir="rtl"而子级含display: inline-flex，该值可能被错误解析为左外边距 - Firefox 85 前对嵌套
bdi元素内使用margin-inline会回退到margin-left计算逻辑 - Chrome 90+ 已基本修复，但若页面启用了
forced-colors: active（Windows 高对比模式），仍可能触发 fallback 行为
如何用兼容性写法安全降级？
不要依赖单一逻辑属性，而是用 @supports + 物理属性兜底，同时避免在关键布局节点上混合使用 margin-inline 和 margin-left/right。
- 优先写物理属性，再用
@supports (margin-inline: 1em)覆盖：这样既保证旧浏览器可用，又让新引擎走逻辑路径 - 对双方向敏感区域（如按钮组、表单标签），显式设置
unicode-bidi: plaintext或isolate，防止 bidi 重排序干扰 margin 解析 - 避免在
fieldset或details等原生元素内部直接用margin-inline—— 这些元素在 Safari 15.4 前存在 shadow DOM 边界解析 bug
button {
margin-left: 0.5em;
margin-right: 0.5em;
}
@supports (margin-inline: 1em) {
button {
margin-inline: 0.5em;
}
}
哪些场景必须手动检测并干预？
当你的组件需要支持阿拉伯语/希伯来语用户且运行在 iOS 15.6 或 Android WebView（Chrome 89–98）时，margin-inline 在 flex 容器中的行为不可信。
- 使用
getComputedStyle(el).marginInlineStart检测实际解析值 —— 若返回"0px"而你写了"0.75em"，说明引擎已 fallback - 在 RTL 页面中，若某元素需「始终靠右」，别只靠
margin-inline-end: auto，补上margin-left: auto（注意顺序：物理属性写在逻辑属性之后才有效覆盖） - 动态插入的元素（如通过
innerHTML添加）在 Firefox 中可能丢失dir继承链，导致margin-inline-start映射失败，此时需手动调用el.setAttribute('dir', 'rtl')
最易被忽略的是：逻辑 margin 的生效依赖于完整的书写模式上下文，而不仅仅是 dir 属性。如果父级用了 writing-mode: vertical-rl，margin-inline 就变成上下方向 —— 很多开发者只测试了水平 RTL，却没覆盖垂直排版场景。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
