width/height 按逻辑轴（内联轴/块级轴）计算，具体方向由 writing-mode 和 direction 决定；默认 horizontal-tb 时 width 水平、height 垂直，vertical-rl 时 width 变为垂直方向。
width/height 是按内联轴还是块级轴计算的？
它们只管内联轴方向（即 width 对应内联尺寸，height 对应块级尺寸），但具体哪条轴是“内联”或“块级”，取决于 writing-mode 和 direction。默认 writing-mode: horizontal-tb 时，内联轴水平（width）、块级轴垂直（height）；换成 vertical-rl 后，width 就变成控制高度方向了。
常见错误现象：width: 100px 在竖排文字里看起来“变窄了”，其实是它现在约束的是行高方向，不是你直觉里的“横向宽度”。
-
width始终对应内联轴尺寸，height始终对应块级轴尺寸 - 不要硬记“width 是横的”，要看
getComputedStyle(el).writingMode - 用
inline-size/block-size替代width/height可以规避方向依赖
padding/margin 的逻辑属性怎么映射到物理方向？
逻辑属性如 padding-inline-start、margin-block-end 会根据 writing-mode 和 direction 自动转成对应的上/右/下/左。比如在 vertical-rl + dir="rtl" 下，padding-inline-start 实际作用在元素的右侧（即内联起始侧），而非 CSS 书写时的“左边”。
容易踩的坑：直接用 padding-left 写多语言布局，切到阿拉伯语或中文竖排时留白错位。
立即学习“前端免费学习笔记（深入）”；
- 优先用
padding-inline/margin-block等逻辑属性，而非padding-left -
inline-start总是当前文本流的开头侧，不等于“左” - 浏览器兼容性：Firefox 66+、Chrome 87+、Safari 14.1+ 支持完整逻辑属性，旧版需降级 fallback
box-sizing: border-box 在逻辑盒模型里还靠谱吗？
靠谱，而且行为完全一致：box-sizing: border-box 仍让 inline-size 或 width 包含 padding 和 border，只是“包含谁”的方向随逻辑轴动态对齐。它不关心物理方向，只认当前块级/内联轴的边界定义。
性能影响几乎没有，但混淆点在于：当你同时混用物理属性（padding-left）和逻辑属性（inline-size），box-sizing 的作用范围可能不对齐，导致尺寸计算意外。
-
box-sizing对逻辑属性和物理属性一视同仁 - 避免在同一元素上交叉使用
padding-left和inline-size，否则 border/padding 归属轴可能错乱 - 调试时用
getComputedStyle查inline-size和block-size，比看width/height更可靠
display: inline-block 元素的基线对齐为什么总出问题？
因为它的基线默认取内容最后一行内联盒的基线，而这个“最后一行”受 writing-mode 影响——竖排时，“行”的概念翻转，基线位置就飘了。再加上 vertical-align 默认值是 baseline，不是 top 或 middle，很容易在混合排版中错位。
典型场景：图标用 inline-block 插入竖排段落，结果上下跳动。
- 显式设
vertical-align: top或vertical-align: text-top，别依赖默认 - 用
display: inline-flex替代inline-block，对齐更可控 - 如果父容器是
writing-mode: vertical-rl，子元素的vertical-align实际作用于水平方向，这点极易忽略
逻辑轴不是语法糖，它是盒模型真正的工作语言。写错一个 writing-mode，所有 inline-size 和 margin-block 就都得重想一遍。
