chrome 中 margin-inline 不生效通常因浏览器版本过低（需 chrome 87+）或未正确设置 writing-mode；其映射方向依赖书写模式，默认 horizontal-tb 下等价于 margin-left/right，vertical-rl 下则控制上下边距。
margin-inline 在 Chrome 里不生效？先看浏览器支持和书写模式
不是代码写错了，大概率是 margin-inline 没在正确的上下文里运行。它依赖 CSS 的书写模式（writing-mode）和浏览器对逻辑属性的支持程度。
- Chrome 87+、Firefox 63+、Safari 15.4+ 才稳定支持
margin-inline-start/margin-inline-end；margin-inline（简写）在 Safari 16.4+ 才完整支持 -
margin-inline默认按块流方向映射：在writing-mode: horizontal-tb（默认）下等价于margin-left/margin-right；但在vertical-rl下，它就变成控制“上下”边距了 - 如果父容器没显式设
direction或writing-mode，且你又在 RTL 语言环境（如dir="rtl"）中测试，margin-inline-start实际会作用在右边——这点极易误判为“失效”
padding-block 要替代 padding-top/bottom？注意 flex/grid 容器的轴向干扰
padding-block 看似只是换了个名字，但它绑定的是“块轴”，而块轴方向由容器的 display 类型和 writing-mode 共同决定。在 flex 或 grid 布局里，这个轴可能已经偏移了。
- 在
display: flex; flex-direction: column中，块轴 = 主轴 = 垂直方向 →padding-block控制上下 - 但在
display: flex; flex-direction: row中，块轴 = 交叉轴 = 垂直方向 → 此时padding-block依然控制上下，和预期一致 - 真正容易翻车的是
display: grid+grid-auto-flow: column：块轴变成水平方向，padding-block就开始影响左右边距，而不是你想要的“上下” - 别直接全局替换旧代码：用
padding-block前，先确认容器的block-size是否是你想撑开的方向
margin-inline 和 padding-block 混用时，为什么元素位置飘忽不定？
当同时用 margin-inline 和 padding-block，尤其是嵌套在不同书写模式的容器中时，它们各自参照的“逻辑方向”可能错位。这不是 bug，是规范设计使然——但现实里很难一眼看出哪一层变了轴向。
- 外层
div设了writing-mode: vertical-rl，内层span没重置，那么它的margin-inline就是控制“上下”，而padding-block控制“左右” - 用 DevTools 检查 computed 样式时，不要只看声明值，要点开
margin-inline-start查看「resolved value」——它会明确告诉你当前解析成了margin-left还是margin-top - 避免跨多层逻辑方向嵌套：比如父容器
vertical-rl+ 子容器dir="rtl"+ 孙元素再设margin-inline，这时映射链太长，调试成本陡增
要不要现在就在生产项目里用？看你的兼容需求和组件粒度
逻辑属性不是“高级语法糖”，它是为多语言、多方向 UI 准备的底层能力。但上线前得掂量两点：构建工具是否抹平了旧浏览器 fallback，以及团队是否能统一理解“块轴/内联轴”的实际指向。
立即学习“前端免费学习笔记（深入）”；
- PostCSS 插件（如
postcss-logical）可将margin-inline编译为margin-left/margin-right，但仅适用于静态书写模式；动态切换writing-mode时仍需 JS 配合 - 组件级使用比全局替换更安全：比如一个支持 LTR/RTL 的卡片组件，内部用
padding-block控制标题与内容间距，外部容器保持物理属性，边界清晰 - 最常被忽略的一点：CSS 自定义属性（
--spacing-block）不能直接赋给padding-block，必须写成padding-block: var(--spacing-block)；漏掉var()包裹会导致整条声明失效，且无任何报错提示
