盒模型不会自动适应字体大小，关键在于控制行高、对齐方式和尺寸约束逻辑；box-sizing: border-box 不影响字体垂直度量，line-height 优先于 height 决定内容高度。
盒模型不会自动“适应”字体大小——它根本不管字体，只管你写的 height、padding、line-height 和字体度量（ascent/descent）共同撑出来的实际高度。想让视觉上“贴合”，关键不是让盒子追着字体变，而是控制好行高、对齐方式和尺寸约束逻辑。
为什么 box-sizing: border-box 对字体撑高无效
box-sizing: border-box 只决定 border 和 padding 是否计入 width/height，完全不干预字体内部的垂直度量。哪怕你写 height: 24px; box-sizing: border-box;，只要当前字体的 font-size × line-height + ascent/descent > 24px，内容就会溢出或换行。
- 浏览器渲染时，文字实际占据的高度 ≈
font-size × line-height（无单位值），再叠加字体自身的上升/下降区域（ascent/descent），这部分是不可控的底层度量 -
line-height: 20px这类绝对值会破坏响应性：字号缩小时，行高不变，留白突兀；字号放大时，行高可能不够，文字挤压 - 真正起作用的是
line-height的计算结果，而不是你写的数值本身
用 flex + align-items 替代硬设 height
固定高度容器 + 文字居中是最容易翻车的组合。与其死守 height: 40px，不如把垂直对齐交给 flex 布局。
- 给容器加
display: flex; align-items: center;，文字自然垂直居中，且不依赖line-height撑高 - 配合
overflow: hidden可防止超出行高的内容外溢（比如sup、emoji 或 fallback 字体突然拉高） - 避免同时设
height和line-height：二者冲突时，line-height优先影响行框高度，height只是盒模型边界，不约束内容渲染 - 按钮类组件更推荐用
padding控制整体尺寸，例如padding: 8px 16px;，比靠line-height撑高稳定得多
fit-content 不是万能解，尤其对含文字的盒子
width: fit-content 看似能“包裹文字”，但对纯文本容器常失效——它按内容的“最大内联尺寸”计算，而文字高度由行高决定，宽度却受换行、空格、white-space 影响。
立即学习“前端免费学习笔记（深入）”；
- 默认
display: block的div设了fit-content却没变化？大概率是父容器有max-width或内部用了flex/grid，干扰了尺寸计算 - 含长单词或
white-space: nowrap时，fit-content等价于max-content，盒子会无限拉宽，甚至溢出 - 真要“文字多宽盒子多宽”，优先用
display: inline-block（兼容 IE8+），天然行为就是内容定宽 - 想兼顾响应式与折行，用
width: max-content; overflow-wrap: break-word;比fit-content更可控
响应式字体下，盒模型高度偏差会被放大
用 clamp() 或 vw 动态调字号时，若没同步调整 line-height，高度偏差会随视口变化剧烈波动——比如 iPhone 横屏下 font-size 缩到 14px，但 line-height: 20px 没变，留白比例就失衡了。
- 始终用无单位
line-height（如line-height: 1.5），它会随font-size等比缩放 - 中英混排场景，
line-height: 1.5–1.7是较安全区间；低于 1.4 容易塌陷，高于 1.8 易撑裂布局 - 容器查询（
@container）搭配cqw单位可实现“按容器宽调字号”，但需显式声明container-type: inline-size，Safari 14.1+ 才稳定支持 - 测试时打开 Chrome DevTools → Rendering → Show layout shift regions，能直观看到文字渲染区域是否超出预期盒模型
最麻烦的点从来不是怎么写 CSS，而是字体度量本身不可控——不同字体、不同系统、甚至同一字体在不同字号下的 ascent/descent 都可能不同。所以别指望盒子“自动适应”，得主动用 flex 分配空间、用无单位 line-height 锁定比例、用 padding 代替 height 控制尺寸。
