padding-top 在 vertical-rl 下朝行首方向（右侧）生效，因其语义绑定 writing-mode 定义的块流方向；逻辑属性 padding-block-start 始终对应 block-start 边，兼容所有书写模式。
padding-top 在 vertical-rl 下到底往哪边走
它不往上，也不往右，而是朝“行首方向”走——在 vertical-rl 下，行首是右边，所以 padding-top 实际表现为右侧内边距。
这是最常让人困惑的点：CSS 的 top/right/bottom/left 在逻辑布局中不是固定物理方向，而是绑定到当前 writing-mode 定义的块流和行内流方向。
-
writing-mode: horizontal-tb（默认）：padding-top= 向上（物理 y 轴负向） -
writing-mode: vertical-rl：块流向 ↓，行内流向 ←，因此padding-top对应“块起始侧”，即右侧 -
writing-mode: vertical-lr：块流向 ↓，行内流向 →，此时padding-top变成左侧
用 logical property 替代 physical property 更稳
直接写 padding-top 在不同 writing-mode 下语义漂移，容易错配。改用逻辑属性能一劳永逸对齐内容流向。
比如把 padding-top: 12px 换成 padding-block-start: 12px：
立即学习“前端免费学习笔记（深入）”；
-
padding-block-start始终贴着块容器的起始边缘（即block-start），不管它是上、右还是左 -
padding-inline-start始终贴着行内起始边缘（即inline-start），在vertical-rl下就是顶部（因为文字从顶往下排，行内起始=顶） - 所有现代浏览器都支持
padding-block/padding-inline（包括start/end变体），IE 不支持，但 IE 本来就不支持writing-mode: vertical-rl
DevTools 里看到的 padding 方向可能骗人
Chrome 和 Firefox 的元素面板仍按物理方向渲染 padding 高亮（用上下左右箭头图标），即使元素启用了 vertical-rl。你看到的“上方高亮”不代表真往屏幕上方加了 padding。
验证真实行为，得靠两件事：
- 用
getComputedStyle(el).paddingTop查值：它返回的是计算后的物理像素值，但含义已随 writing-mode 重映射 —— 在vertical-rl下，这个值实际影响的是右边界 - 在元素内放一个
background-color+border，再叠加padding，观察内容是否被“推离块起始侧”，比看 DevTools 图标靠谱得多
padding 简写在 vertical-rl 下的顺序陷阱
padding: 10px 20px 30px 40px 这种简写，在 writing-mode: vertical-rl 下依然按 block-start inline-end block-end inline-start 解析，而不是上下右左。
也就是说：
-
padding: 10px 20px 30px 40px在vertical-rl中 =padding-block-start: 10px,padding-inline-end: 20px,padding-block-end: 30px,padding-inline-start: 40px - 对应物理位置是：右、顶、左、底（顺序是顺时针，但映射关系变了）
- 如果误以为还是“上右下左”，就会把 10px 放到期望的“顶部”，结果它出现在右侧，还纳闷为什么内容被挤偏了
逻辑简写 padding-block 和 padding-inline 不支持四值，只能两值（padding-block: 10px 30px）或单值（padding-inline: 20px），反而更难出错。
writing-mode 切换后 padding 的方向映射不是视觉直觉能猜准的，靠记忆物理方位一定会翻车；唯一可靠的是盯住 block-start 和 inline-start 这两个抽象锚点，其它都是它们的投影。
