margin-inline-start自动适配LTR/RTL：它依据元素的direction计算值（继承或显式设置）映射，LTR时为margin-left，RTL时为margin-right，由浏览器样式计算阶段完成，无需JS或class切换，且与writing-mode无关。
margin-inline-start 怎么自动适配 LTR/RTL？
它不看 HTML 的 dir 属性本身，而是读取元素自身的 direction 计算值（继承或显式设置）。LTR 下 margin-inline-start 映射为 margin-left，RTL 下则映射为 margin-right——这个映射由浏览器在样式计算阶段完成，零 JS、零 class 切换。
- 未设置
direction的元素会继承父级；若整条继承链都没设，按浏览器默认（通常是ltr） -
margin-inline-start和writing-mode无关，哪怕writing-mode: vertical-rl，只要direction: ltr，它仍作用于左侧 - 不要在全局重置里写
* { margin-inline-start: 0 }——这会抹掉按钮、输入框等原生控件的起始间距逻辑
margin-inline 简写在 RTL 下会翻转顺序吗？
不会。margin-inline: 12px 8px 永远等价于 margin-inline-start: 12px; margin-inline-end: 8px。起始就是起始，结束就是结束，和当前文本方向无关。
- 常见误用：把
margin-inline: 8px 12px当作“左 8px、右 12px”来记，结果在 RTL 下发现起始侧变右了，视觉错位 - 混用简写和单侧属性时，单侧声明优先级更高：
margin-inline: 10px后再写margin-inline-start: 20px，后者生效但可读性差 - 在
flex或grid容器中对子项用margin-inline-start对齐，要确认子项没被重置direction（比如第三方组件内部强制设了ltr）
为什么不用媒体查询 + 物理属性做 RTL 切换？
物理方案需要监听 dir 变更并注入新 class，或靠 CSS 自定义属性 + JS 计算，容易漏掉深层嵌套节点；而 margin-inline 是纯声明式、零运行时开销的原生能力。
- 第三方组件库（如 Ant Design、MUI）若未启用逻辑属性，其 RTL 支持往往依赖独立 RTL CSS 文件，此时混用
margin-inline可能冲突 - 当
direction和writing-mode同时存在时，margin-inline以direction为准，margin-block才听writing-mode的 -
text-align: start比text-align: left更安全，它随direction自动切换对齐端，且兼容性更好
border-start-start-radius 这类圆角属性怎么理解？
它描述的是“块轴起始端 + 内联轴起始端”的交点处的圆角，不是“左上角”。所以它在 LTR 和 RTL 下可能指向不同物理位置，但语义始终一致：内容流的起始角落。
立即学习“前端免费学习笔记（深入）”；
-
border-start-start-radius在direction: ltr下是左上，在direction: rtl下是右上 - 不要试图用它替代
border-top-left-radius来“微调像素”，它的设计目标是语义一致性，不是像素级控制 - 如果项目需支持垂直书写（如
writing-mode: vertical-rl），border-block-start才真正对应顶部边框，border-top会失效
逻辑属性的复杂点不在语法，而在思维切换：你得习惯不再问“左边还是右边”，而是问“内容从哪开始流”。一旦建立这个直觉，margin-inline-start 就不再是新语法，而是唯一合理的写法。
