margin-inline-start 始终对应文本流起始侧，由元素自身或祖先的 direction 计算值决定：LTR 时为左，RTL 时为右；其行为与 writing-mode 无关，margin-block 才受 writing-mode 影响。
逻辑属性不是“更高级的语法糖”，而是解决方向耦合问题的底层机制——margin-inline-start 在 LTR 下映射 margin-left，在 RTL 下自动变成 margin-right，无需 JS 切换 class，也不用维护两套 CSS。
margin-inline-start 和 margin-inline-end 怎么响应 direction 变化？
它们不读取 HTML 的 dir 属性本身，而是依赖当前元素的 direction 计算值（继承或显式设置）。只要该元素或其祖先设置了 direction: rtl，margin-inline-start 就会作用于右侧；LTR 下则作用于左侧。
注意几个关键点：
-
margin-inline-start始终对应“文本流起始侧”，和书写方向无关，只和direction有关 -
margin-block-start的行为由writing-mode决定（比如writing-mode: vertical-rl时，它指向顶部） - 如果同时设置了
direction和writing-mode，margin-inline仍以direction为准，margin-block才听writing-mode的 - 未显式设置
direction的元素，会继承父级，若一直没设，则按浏览器默认（通常是ltr）
margin-inline 简写在 RTL/LTR 下是否安全？
安全，但要理解它的展开规则：margin-inline: 12px 8px 等价于 margin-inline-start: 12px; margin-inline-end: 8px。这个顺序不会因为 RTL 而翻转——起始永远是起始，结束永远是结束。
立即学习“前端免费学习笔记（深入）”；
常见误用场景：
- 把
margin-inline: 8px 12px当作“左 8px、右 12px”来记，结果在 RTL 下发现“起始侧”变右了，间距错位 - 混用简写和单侧属性，比如先写
margin-inline: 10px，又单独覆盖margin-inline-start: 20px，后者会生效，但可读性差 - 在 flex 或 grid 容器中对子项用
margin-inline-start实现对齐，却忘了子项的direction可能被重置
为什么 margin-inline 比媒体查询 + 物理属性更适合响应式 RTL 切换？
物理方案需要监听 dir 变更并注入新 class，或靠 CSS 自定义属性 + JS 计算，容易漏掉深层嵌套节点；而 margin-inline 是纯声明式、零运行时开销的原生能力。
实际项目中要注意：
- 不要在全局重置里写
* { margin-inline-start: 0 }—— 会破坏所有按钮、表单控件的默认起始间距逻辑 - 第三方组件库（如 Ant Design、MUI）若未启用逻辑属性，其 RTL 支持往往靠独立 RTL CSS 文件，此时混用
margin-inline可能冲突 - 旧版 Safari（≤15.4）对
margin-inline简写支持不全，需检查目标用户覆盖率，必要时降级为单侧属性 -
margin-inline不影响float或position: absolute的偏移计算，它只控制外边距，别指望它替代inset-inline-start
真正难的不是写对 margin-inline-start，而是让整个团队理解：起始（start）不是“左边”，而是一个随语言流动的方向锚点——一旦这个认知没对齐，再规范的代码也会在协作中被悄悄 revert 掉。
