margin-inline-start 替换 margin-left 不等于适配 rtl，需配合 direction 或 writing-mode 设置；其方向由文本流决定，ltr 为左、rtl 为右、vertical-rl 下为顶部，且必须同步更新 margin-right 等对应逻辑属性以保持语义一致。
直接用 margin-inline-start 替换 margin-left 不等于“适配 RTL”，它只是逻辑属性的起点；真正起效的前提是 direction 或 writing-mode 已被正确设置，且上下文语义一致。
为什么 margin-inline-start 在 RTL 下没翻转？
这不是属性失效，而是浏览器按默认 direction: ltr 解析——margin-inline-start 在 LTR 下就等于 margin-left，在 RTL 下才映射为 margin-right。常见错误包括：
- HTML 根节点漏写
dir="rtl"，或 CSS 里没设direction: rtl - 只改了子元素的
margin-inline-start，但父容器仍用float: right或text-align: right这类物理方向控制，造成逻辑/物理混用冲突 - 用了
margin-inline: 10px（单值），这是非法语法，浏览器直接忽略整条声明
margin-inline 和 margin-left 的行为差异在哪？
区别不在“能不能推元素”，而在“推的方向由谁决定”：
-
margin-left永远绑定屏幕左侧，不管文字往哪流、页面朝哪翻 -
margin-inline-start绑定当前文本流的“起始侧”：LTR 是左，RTL 是右，writing-mode: vertical-rl下则变成顶部 -
margin-inline: 10px 16px是合法写法，等价于margin-inline-start: 10px; margin-inline-end: 16px；但margin-inline: 10px❌ 无效 - 不支持 IE11，Safari 14.0 以下对两值简写解析不稳定，建议生产环境用长手属性显式书写
哪些地方必须改，哪些可以不动？
不是所有 margin-left 都要动，重点盯住三类场景：
- 被复用的 UI 组件类（如
.btn-group > * + *的间距控制）——一旦支持 RTL，物理边距必然错位 - 配合
dir="rtl"使用的布局容器（如阿拉伯语弹窗、希伯来语表单区域） - 图标与文字的相对位置（例如按钮内图标靠左，RTL 下应保持“操作主语在前”，此时该用
margin-inline-end: 8px而非margin-inline-start） - 纯装饰性微调（如
transform: translateX(-2px)微移图标）、绝对定位的left值、或已用flex-direction: row-reverse显式翻转的容器，可暂缓替换
迁移时最容易踩的坑
逻辑属性不是字符串替换，它把方向决策权交给了浏览器渲染引擎，所以出问题往往不是某一行代码错了，而是上下文断层：
- 只改
margin-left → margin-inline-start，却没同步改margin-right → margin-inline-end，导致两侧间距逻辑不对称 - 在
dir="rtl"页面里嵌了一个 LTR 子组件（比如英文图表），但子组件内部仍用margin-inline-start，结果被外层 direction 强制翻转，反而错位 - 用 PostCSS 自动生成 RTL 规则时，同时保留了
margin-left和margin-inline-start，旧浏览器读到后者报错或忽略，新浏览器又因优先级覆盖产生意外表现 - 以为
margin-block只管上下，其实它受writing-mode控制：vertical-rl 下，margin-block-start对应的是左边，不是顶部
真正难的不是写出一个正确的 margin-inline-start，而是确保从 HTML dir 属性、根元素 direction、组件封装粒度，到构建时的兼容性 fallback，整条链路的方向语义是连贯且自洽的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
