应优先使用margin-inline替代margin-left/right以适配RTL语言或多书写方向场景，因其依direction和writing-mode动态映射方向；纯LTR页面使用无实质优势且降低可读性。
什么时候该用 margin-inline 替代 margin-left
当你需要适配 RTL（从右向左）语言（如阿拉伯语、希伯来语）或未来可能切换文本方向的组件时，margin-inline-start 和 margin-inline-end 才是安全选择。margin-left 在 RTL 下会固定作用于物理左侧，导致布局错位——比如导航菜单项在阿拉伯语中本该右对齐，却因 margin-left 被强行往左推。
常见错误现象：dir="rtl" 下按钮组间距反向、表单标签与输入框错位、卡片外边距“消失”或重叠。
- 适用场景：导航栏项间隔、表单控件左右留白、卡片级外边距、文字图标对齐间距
- 不适用场景：纯 LTR 视觉微调（如图标向左偏移 2px）、绝对定位中依赖物理坐标的
left/right值（此时应改用inset-inline-start） - 注意：若容器已用
text-align: right或flex-direction: row-reverse控制流向，内部子元素再用逻辑外边距可能冗余，优先检查是否已有逻辑流向控制
padding-inline 和 padding-block 的实际取值逻辑
padding-inline 控制行内方向（即文本流方向）的左右内边距，padding-block 控制块方向（即书写方向垂直轴）的上下内边距。它们不是简单映射为 “左右/上下”，而是随 direction 和 writing-mode 动态变化。
例如：writing-mode: vertical-rl（竖排右到左）下，padding-inline: 16px 作用于顶部和底部，padding-block: 12px 则作用于右侧和左侧——这和直觉相反，但符合逻辑坐标系。
立即学习“前端免费学习笔记（深入）”；
- 推荐写法：
padding-inline: 1rem替代padding-left: 1rem; padding-right: 1rem - 慎用简写：
padding: 1rem 1.5rem仍是物理方向，无法响应dir变化；逻辑属性暂不支持四值简写 - 兼容性提醒：Firefox 66+、Chrome 87+、Safari 15.4+ 支持完整逻辑 padding，IE 完全不支持，无需 polyfill，但需确认目标环境
盒模型总尺寸计算仍受 box-sizing 控制
逻辑属性只改变“哪一边”被设置，不改变尺寸计算规则。padding-inline 增加的内边距依然计入元素总宽高，是否溢出仍取决于 box-sizing 值。
典型陷阱：开发者改用 padding-inline-start: 20px 后发现元素变宽，误以为逻辑属性“自带 box-sizing 优化”，其实只是忘了重置 box-sizing: border-box ——尤其在 reset.css 未全局设置时，content-box 下 20px 内边距仍会额外撑开宽度。
- 必须同步检查：
*, *::before, *::after { box-sizing: border-box; } - 逻辑属性 +
border-box是现代间距控制的黄金组合，否则width: 100%容器加padding-inline: 1rem仍会水平溢出 - 不要指望
margin-inline触发 margin collapse 的逻辑方向适配——垂直方向的塌陷行为不变，仅作用于块轴
哪些地方最容易漏掉逻辑化改造
重构常止步于显眼的 margin-left，但真正影响多语言体验的是那些“看起来无关紧要”的地方。
比如 .btn-group > button:not(:first-child) { margin-left: 8px; } 这类兄弟选择器间距，在 RTL 下直接失效；又如 input[type="checkbox"] + label { margin-left: 0.5em; } 中的复选框标签对齐，RTL 下标签会跑到 checkbox 左侧而非右侧。
- 重点扫描：所有带
:not(:first-child)/:not(:last-child)的兄弟间距规则 - 警惕伪元素：
::before/::after中使用left或right定位图标时，应同步改为inset-inline-start - 组件库 class 命名如
.ml-2（margin-left 0.5rem）必须废弃，改用.ms-2（margin-start）等逻辑前缀，否则主题切换时无法自动适配
