逻辑内外边距是RTL和垂直书写场景下的刚需方案，因margin-left等物理属性不感知direction和writing-mode，易致UI错位；而margin-inline-start等逻辑属性自动映射：LTR时为left、RTL时为right、vertical-rl时为top。
逻辑内外边距（margin-block、padding-inline 等）不是“锦上添花”，而是解决 RTL（从右到左）和垂直书写场景下样式失控的刚需方案。如果你还在用 margin-left 和 padding-right 写多语言项目，大概率已经靠 [dir="rtl"] 覆盖层硬 patch 过至少三次。
RTL 页面中 margin-left 变成 margin-right 时，为什么手动覆盖总出错？
因为物理方向属性与文本流向完全脱钩：写死 margin-left: 16px 在阿拉伯语页面里会把按钮推到屏幕右侧之外，而开发者常漏掉某些嵌套层级或伪元素（比如 ::before 的定位偏移）。更麻烦的是，当 writing-mode: vertical-rl（如日文竖排）启用后，margin-top 不再是“顶部”，而是“块级起始侧”——此时物理属性彻底失效。
- 错误现象：
margin-left在 RTL 下未反转，导致 UI 元素重叠或截断 - 根本原因：物理属性不感知
direction和writing-mode，必须靠人工判断映射 - 逻辑属性自动响应：
margin-inline-start在 LTR 下 =margin-left，在 RTL 下 =margin-right，无需额外 CSS - 注意：
dir()伪类仍需保留用于微调，比如某些图标在 RTL 下需额外margin-inline-start: 24px
vertical-rl 模式下 padding-top 失效，该用哪个逻辑属性？
垂直书写时，“上/下”概念消失，取而代之的是“块级起始/结束”（block-start/block-end）和“内联起始/结束”（inline-start/inline-end）。例如日文竖排菜单，文字从上到下排列，此时“顶部”对应的是内容流的起点，即 padding-block-start，而不是 padding-top。
- 典型场景：东亚语言产品支持竖排阅读模式、电子书阅读器、政府公文系统
- 简写优先用
padding-block: 12px 8px（start end），比展开写四行更安全 - 兼容性提醒：Chrome 87+、Firefox 63+、Safari 15.4+ 均已稳定支持；IE 完全不支持，但 2026 年新项目基本可忽略
- 不要混用：避免在同一选择器里同时写
padding-top和padding-block-start，后者会覆盖前者
为什么 margin-block: 1rem 2rem 的顺序是 start end，而不是 top bottom？
因为逻辑简写不按物理坐标系，而严格遵循书写流的方向轴：block 轴永远沿内容块的流动方向（默认是 vertical-tb，即从上到下），所以 margin-block: A B 永远表示 “块起始边距为 A，块结束边距为 B”，无论页面是横排还是竖排、LTR 还是 RTL。
立即学习“前端免费学习笔记（深入）”；
- 对比物理简写：
margin: 1rem 2rem是 “top right bottom left”，依赖固定方向 - 逻辑简写无歧义：
margin-inline: 1rem表示左右两边都为 1rem；margin-inline: 1rem 2rem表示 inline-start=1rem，inline-end=2rem - 容易踩的坑：误以为
margin-block: 1rem 2rem是 “上 1rem，下 2rem”，在writing-mode: vertical-rl下会导致左侧（块起始）1rem、右侧（块结束）2rem —— 这恰恰是正确行为，只是不符合直觉
真正难的不是记住哪些属性名，而是在设计系统初期就放弃“先写 LTR、再 patch RTL”的路径依赖。一旦组件内部混用物理和逻辑属性，后续维护成本会指数上升——尤其当团队多人协作、样式分散在多个文件时，margin-inline-start 是否被某个 !important 覆盖，往往要调试五分钟才能定位。
