inline-size不是width的平替，仅在需响应writing-mode或多语言混排时有意义；默认horizontal-tb下二者等价，但引入兼容风险与可读成本。
直接说结论：inline-size 不是 width 的平替，它只在真正需要响应书写方向（writing-mode 或多语言混排）时才有意义；默认水平布局下写 inline-size: 300px 和写 width: 300px 效果一样，但多了兼容风险和可读成本。
什么时候 inline-size 才会“动”起来
inline-size 的尺寸方向完全由最近的 writing-mode 决定，direction: rtl 单独存在时不会触发逻辑轴切换——这是最常被误解的一点。
-
writing-mode: horizontal-tb（默认）→inline-size=width -
writing-mode: vertical-rl→inline-size控制的是“高度方向”（即原本height对应的物理轴） -
writing-mode: vertical-lr→ 同样，inline-size指向垂直方向，但块流从左往右 -
direction: rtl+horizontal-tb→inline-size仍等价于width，只是内联起始位置变了
百分比和 auto 行为容易踩坑
inline-size: 50% 的基准不是父容器宽度，而是父容器在「当前 inline 轴」上的尺寸。这个轴随 writing-mode 动态变化，调试时很容易误判。
- 在
vertical-rl下，inline-size: 50%是相对于父容器的 高度，不是宽度 -
inline-size: auto在 Flex/Grid 容器中行为不稳定：可能被拉伸（尤其当父设了align-items: stretch），而width: auto在同场景下通常收缩贴内容 -
max-content/min-content在 iOS 16.x Safari 中不支持，inline-size: max-content会退化为auto，需加width: max-contentfallback
不能只换 inline-size，配套属性必须同步改
单独把 width 换成 inline-size 而保留 padding-left、border-top 等物理属性，会导致盒模型错位——因为边框/内边距依然按物理方向渲染，而尺寸已按逻辑轴计算。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 改了
inline-size，就要配padding-inline、margin-inline-start、border-inline-end - 改了
block-size，就要配padding-block、margin-block-end、border-block-start -
box-sizing: border-box对逻辑属性同样生效，但若混用padding-left和inline-size，border-box的“边界”归属轴会混乱，实测尺寸偏小 - Safari 15.6 及更早版本中，
inline-size+border-box可能忽略border-inline，导致视觉尺寸缩水
迁移前必须做的三件事
别全局搜索替换 width → inline-size。先确认：
- 该组件是否明确要支持竖排（如日文/中文古籍阅读界面）或多语言 RTL+LTR 混排？否则没必要动
- 父级或自身是否已设
writing-mode？没设就等于白改，inline-size仍走物理路径 - 所有相关盒模型属性（padding/margin/border/box-sizing）是否已统一为逻辑写法？漏一个就可能让布局错乱
真正复杂的点不在语法，而在轴对齐——inline-size 是个开关，打开后整个盒模型的方向语义都得重校准，稍有遗漏，尺寸、间距、基线全都会飘。
