margin-inline在IE11、Edge17及更早、Safari12–14、Android4.4 WebView中静默丢弃，不报错；因旧浏览器不识别@supports语法，故fallback必须显式写在外部且传统声明需前置，逻辑属性后置覆盖。
margin-inline 在 IE11、Edge 17 及更早、Safari 12–14、Android 4.4 WebView 中完全不生效，且不会报错，而是静默丢弃整条规则。这意味着你写 margin-inline: 1rem，旧浏览器直接跳过，既不解析也不 fallback——必须手动提供传统方向声明。
为什么不能只靠 @supports 做渐进增强
@supports (margin-inline: 0) 在旧浏览器中本身是非法语法：IE11、Edge 17 等压根不识别 @supports 规则，整个块会被跳过。即使你写了 fallback，它如果被包在 @supports 里面，就根本不会执行。
- 旧浏览器连
@supports关键字都不认识，不是“条件不满足”，而是“语法错误→忽略整段” - PostCSS 等工具若配置了自动剥离不支持的特性，可能提前移除该规则，导致生产环境彻底丢失样式
- 真实运行时无任何控制台警告，问题表现为“样式莫名消失”，排查成本高
正确 fallback 写法：顺序决定成败
必须把传统写法放前面，逻辑属性放后面——浏览器按顺序解析，旧浏览器停在第一行，新浏览器覆盖第二行。
button {
margin-left: 1rem;
margin-right: 1rem;
margin-inline: 1rem; /* 仅新浏览器生效，覆盖上面两行 */
}- 顺序反了（先写
margin-inline）会导致新浏览器也走传统逻辑，失去 RTL 自适应优势 - 不要用
!important强制覆盖——它会干扰后续其他 margin 调整，且在部分旧引擎中行为不稳定 - 若需不同值（如
margin-inline: 1rem 2rem），对应写成margin-left: 1rem; margin-right: 2rem;（LTR）或手动交换（RTL）——但此时已失去逻辑属性的核心价值
替换时最容易忽略的三个行为差异
直接把 margin-inline 替换成 margin-left/margin-right 不只是换名字，布局语义可能悄悄偏移：
立即学习“前端免费学习笔记（深入）”；
-
margin-inline-start始终指向内容起始侧（LTR 是左，RTL 是右），而margin-left永远是物理左侧——父容器direction: rtl时，视觉位置会错位 - 在 Flex/Grid 容器中，
margin-inline仍作用于块轴（垂直方向），margin-left固定作用于内联轴（水平方向），混用易导致对齐混乱 -
margin-inline: 1rem 2rem在 RTL 下等价于margin-left: 2rem; margin-right: 1rem，硬编码左右值无法自动适配
真正需要兼容旧内核时，逻辑属性不是“能用就用”，而是“用了就必须承担 fallback 的完整责任”——尤其是当项目仍需支持 IE11 或老版 Safari 时，margin-inline 的声明永远要和它的传统双胞胎成对出现，且顺序不可颠倒。
