结论：不设 box-sizing: border-box 的生产环境必然导致布局错位，因其触发浏览器默认 content-box 尺寸计算与实际需求的底层冲突，全局重置 、::before、*::after 为 border-box 是不可跳过的首要步骤。
直接说结论：不设 box-sizing: border-box 的生产环境，布局错位不是“会不会发生”，而是“什么时候爆发”。它不是样式细节问题，而是尺寸计算规则的底层冲突。
为什么全局重置 box-sizing 是不可跳过的一步
浏览器默认用 content-box 解析所有 width 和 height，意味着你写 width: 300px; padding: 16px; border: 2px，实际占宽是 336px。这个偏差在卡片、表单、栅格列中会逐层放大，最终表现为横向滚动、最后一列掉行、弹窗遮挡内容等“诡异现象”。
真正有效的解法只有一条：在项目最顶层 CSS 文件开头，无条件插入：
*, *::before, *::after {
box-sizing: border-box;
}- 必须包含
*::before和*::after，否则伪元素仍走content-box，比如tooltip里的箭头或badge的角标可能悄悄撑破容器 - 这条规则必须在所有自定义样式之前加载，否则会被后续声明覆盖
- 不要加
!important，它掩盖的是选择器权重问题，不是根本原因
第三方 UI 库破坏 box-sizing 的典型表现与修复方式
Ant Design、Element Plus、旧版 Bootstrap 等库常在组件内部强制写 box-sizing: content-box，尤其集中在 input、button、select 上。现象是：表单控件在父容器里溢出、左右留白不均、和文字对不齐。
立即学习“前端免费学习笔记（深入）”；
不能靠“一个个改 class”，而要针对性覆盖：
.ant-input,
.ant-btn,
.el-input__inner,
.bootstrap-input {
box-sizing: border-box !important;
}- 用浏览器 DevTools 的 “Computed” 面板查具体哪个元素被覆盖了，再精准定位选择器
- 避免用
!important覆盖整个库，只打补丁；否则升级库版本时容易漏掉新组件 - iframe、canvas、video 这类替换元素（replaced elements）天生不响应
box-sizing，需单独处理，比如给img加display: block消除基线空白
JS 动态计算尺寸时容易忽略的兼容点
很多逻辑依赖 offsetWidth 或 getBoundingClientRect() 做宽度判断、位置对齐、动画起始值。如果代码是按 content-box 时代写的，切换到 border-box 后，这些值会变小——因为 padding 和 border 不再额外叠加。
- 检查所有涉及
el.offsetWidth - 2 * padding或类似手工扣减的逻辑，大概率已失效 - 用
getComputedStyle(el).paddingLeft+getComputedStyle(el).borderLeftWidth替代硬编码数值，更健壮 - 动态插入的 DOM（如 JS 创建的 toast、modal）若没走主 CSS 入口，会漏掉全局重置，建议在插入后手动触发
el.style.boxSizing = 'border-box'
最麻烦的从来不是加那行全局重置，而是它暴露了旧代码里所有靠“经验估算”留白的脆弱假设。一旦开启 border-box，所有靠“多写几个像素抵 padding”的写法都要重审——这不是回归测试能发现的，得靠人眼扫一遍关键布局区域。
