content-box与border-box无实质性能差异，所谓“变慢”实为content-box下padding/border变更引发父容器重排，或JS频繁读取offsetWidth强制同步计算所致；border-box因尺寸稳定更利于减少意外重排。
content-box 与 border-box 本身没有运行时性能差异。浏览器渲染引擎对两种 box-sizing 值的处理开销几乎可以忽略，不存在“border-box 更慢”或“content-box 占更多内存”这类实际可观测的性能损耗。
为什么有人误以为有性能差别？
常见误解来源是布局重排（reflow）或重绘（repaint）被间接触发，但根本原因不在 box-sizing 本身：
- 在
content-box下频繁修改padding或border，容易导致元素总尺寸变化 → 触发父容器重排 → 看似“变慢”，实则是布局链式反应 - 用 JS 反复读取
offsetWidth并依赖其值做逻辑判断（比如轮询宽度），无论哪种box-sizing都会强制同步计算，造成卡顿 - 某些旧版 UI 库（如 Bootstrap 3 之前）未统一
box-sizing，混合使用导致样式层叠混乱 → 开发者调试耗时增加，误归因为“性能问题”
真正影响性能的其实是使用方式
关键不在选哪个值，而在是否让尺寸行为可预测、可收敛：
-
border-box让width和height成为稳定锚点 → 减少因 padding/border 变化引发的意外重排，尤其在动画、拖拽、响应式切换中更可控 -
content-box在需要精确控制内容区物理像素（如canvas、textarea行高对齐、等宽字体排版）时更直接，避免手动减去 padding/border 的计算误差 - 用
calc(100% - 20px)配合content-box容易出偏差：因为百分比基于父容器 content-box 尺寸，而减去的 20px 是固定值，叠加 padding 后实际可用空间可能远小于预期
哪些地方真会影响渲染效率？
注意这些常被忽略的副作用点：
立即学习“前端免费学习笔记（深入）”；
-
* { box-sizing: border-box }全局设置后，若未排除表单控件（input、textarea、select），Safari 中某些input[type="search"]会重绘异常，表现为光标抖动或文字截断 —— 这是渲染管线 bug，不是性能差，但用户感知为“卡” - SVG 元素完全不响应
box-sizing，给<svg>或其子元素设该属性无效，还可能干扰 CSS 层叠优先级判断 - 第三方组件库（如 Ant Design）内部已封装盒模型逻辑，外部再全局覆盖
box-sizing可能导致其栅格计算错乱，引发隐式重排
真正要盯住的不是 box-sizing 值本身，而是它如何和你的尺寸控制链耦合——尤其是当 width 来自百分比、calc()、flex-basis 或 JS 动态赋值时，content-box 下的 padding/border 会悄悄把“可控变量”变成“不可控扰动”。
