padding-block 在 vertical-lr 下控制左右而非上下，因其依赖块轴方向；竖排时“上下留白”应使用 padding-inline，它对应行内轴（垂直方向）。
padding-block 在 vertical-lr 模式下为什么没效果
因为 padding-block 依赖当前 writing-mode 的块轴方向，而 vertical-lr 下块轴是水平方向（从左到右），padding-block 实际控制的是左右内边距，不是你直觉里“上下”的那部分。很多人调了半天发现元素没“竖着撑开”，其实是用错了逻辑轴。
- 默认
writing-mode: horizontal-tb：块轴 = 垂直方向 →padding-block控制上下 -
writing-mode: vertical-lr：块轴 = 水平方向 →padding-block控制左右 -
writing-mode: vertical-rl同样控制左右，只是方向相反（右→左）
验证方式很简单：border-block: 2px solid red，看红边出现在哪——它和 padding-block 共享同一对轴。
想让文字竖排时“上下有空隙”，该用哪个属性
得切回行内轴（inline axis）：用 padding-inline。在 vertical-lr 下，行内轴是垂直方向（从上到下），所以 padding-inline 才真正控制你想要的“顶部/底部”留白。
- 场景：竖排中文标题，需要顶部留 12px、底部留 8px
- 写法：
padding-inline: 12px 8px（注意顺序：起始 inline → 结束 inline，即上→下） - 别写
padding-top/bottom：它们在竖排时被忽略或映射错位 - 兼容性提醒：Safari 15.4+ 才完整支持
padding-inline，旧版需 fallback 到padding-left/right+transform: rotate(90deg)等降级方案
box-sizing: border-box 和 padding-block 共存时的计算陷阱
box-sizing: border-box 依然生效，但“box”的基准尺寸会随 writing-mode 动态旋转。也就是说，width 和 height 的语义不变，但它们约束的物理方向变了。
立即学习“前端免费学习笔记（深入）”；
- 在
vertical-lr下：width变成“高度方向尺寸”，height变成“宽度方向尺寸” - 此时
padding-block（控制左右）会从width里扣除，而不是height - 典型翻车：设了
width: 200px; padding-block: 20px，结果可视宽度只剩 160px —— 因为 padding 被从 width 里减了 - 解法：改用
min-inline-size或min-block-size显式控制最小尺寸轴，比硬写width/height更可靠
要不要用 padding-block 替代所有 padding-top/bottom
不是不能，而是得看维护成本和目标环境。如果你的项目已稳定支持 Safari 15.4+、Chrome 87+、Firefox 63+，且书写模式会动态切换（比如中日韩多语言 UI），那值得切。
- 优势：一套代码适配
horizontal-tb/vertical-lr/vertical-rl，不用重复写媒体查询或 JS 切换 class - 风险点：CSS-in-JS 库（如 Emotion）可能解析
padding-block不一致；PostCSS autoprefixer 对 writing-mode 相关属性默认不加前缀，老 Android WebView 会直接失效 - 务实建议：新模块直接用
padding-block/padding-inline；老模块不动，除非真要加竖排支持
真正容易被忽略的，是 padding-block-start 和 padding-block-end 这类更细粒度属性——它们不会随 direction 或 text-align 反转，只认块流方向。需要精确控制起始/结束侧留白时，它们比 padding-block 更稳。
