盒模型本身不慢，慢在修改方式易触发重排；width/height/padding/border 改变会强制重排，hover 加 border 若未设 box-sizing: border-box 可能挤动元素；透明边框预留、border-box 全局设置、慎用 margin（改用 padding 或 flow-root）、outline 比 box-shadow 更轻量。
有影响，但不是盒模型本身慢，而是你改它的方式容易触发重排。
修改 width、height、padding、border 会强制重排
浏览器必须重新计算元素及其后代的位置和尺寸。哪怕只是 hover 时加个 border，只要没提前设好 box-sizing: border-box，就可能撑开容器、挤动兄弟元素，整条流都要重排。
- 常见错误现象：
input聚焦时加border，导致页面“抖一下” - 性能影响：滚动或动画中频繁触发，帧率直接掉
- 规避方式：用透明边框预留空间（如
border: 2px solid transparent），hover 时只改颜色
box-sizing: border-box 不提速，但能防误操作引发的重排
它不减少单次重排耗时，但让 width 和 height 的行为可预测——加 padding 不再意外撑大元素，也就少了一类 JS 补丁式修复（比如反复读 offsetWidth 再手动调尺寸）。
- 使用场景：所有新项目应全局设置
* { box-sizing: border-box; } - 容易踩的坑：第三方库（如旧版 Bootstrap）可能依赖
content-box，上线前需验证卡片、表单等组件是否错位 - 参数差异：设为
border-box后，width: 100%在父子间尺寸传递更稳定；混用两种模型时，子元素width: 100%在父容器里表现不一致
margin 动态修改比 padding 更危险
相邻块级元素的垂直 margin 会合并（margin-collapse），JS 修改任一元素的 margin-top 或 margin-bottom，浏览器就得重新遍历整条流来确认合并关系——这无法被 will-change 优化，且开销常被低估。
立即学习“前端免费学习笔记（深入）”；
- 替代方案：用
padding控制内部间距（不合并） - 若必须用外边距，给容器加
overflow: hidden或display: flow-root切断 margin-collapse 上下文 - 动画中绝对要避开：在
requestAnimationFrame里读getBoundingClientRect()再写margin，等于主动制造同步布局
outline 和 box-shadow 对图层的影响完全不同
outline 永远画在当前图层上，零新增合成层；而 box-shadow（尤其带模糊值）大概率触发新图层，带来额外内存与光栅化成本。
- 焦点提示优先用
outline：轻量、无障碍友好、不拖慢渲染 - 卡片浮起效果用
box-shadow时，避免模糊半径过大（如blur: 24px），必要时加transform: translateZ(0)提前升层，而非等阴影触发 - 注意：
outline-offset不影响图层，但box-shadow的spread值增大后，合成开销会线性上升
真正卡顿的从来不是盒模型定义本身，而是你在 JS 里一边读 offsetHeight，一边改 margin，再切个 display ——这些操作叠加起来，才把浏览器拖进重排泥潭。把 box-sizing 设对、把 margin 换成 padding、把 left 换成 transform，比纠结“该不该用 border”实在得多。
