全局重置 box-sizing: border-box 必须分层处理：先识别真正依赖 content-box 的元素（如 Canvas 容器、SVG foreignObject、旧 JS 尺寸计算），再优先覆盖“被动 content-box”元素（表单控件、卡片、栅格列等），并显式包含伪元素及主流 UI 库组件，避免盲目覆盖导致裁剪或错位。
直接全局重置 box-sizing: border-box 很可能让老项目崩得更快——必须先识别哪些元素真在用 content-box 的逻辑，再分层覆盖。
哪些元素还在“依赖”content-box？
不是所有 content-box 都是遗留问题，有些是显式需要的：比如 Canvas 容器、SVG <foreignObject> 内嵌块、或某些旧版 JS 尺寸计算（如直接读取 getComputedStyle(el).width 并手动加 padding）。盲目覆盖会导致这些地方内容被裁剪或定位偏移。
真正该优先处理的是那些“被动 content-box”：表单控件（input、textarea、select）、卡片类容器、栅格列、Flex/Grid 子项——它们本意是填满可用空间，却因没设 box-sizing 而实际溢出。
- 检查开发者工具「Computed」面板里
box-sizing值为content-box且同时设置了padding或border的元素 - 特别注意伪元素：
::before和::after默认仍是content-box，哪怕父元素已设border-box - 第三方 UI 库组件内部常带装饰性伪元素，漏掉它们就等于留了半截 bug
为什么只写 * { box-sizing: border-box } 不够？
通配符 * 不匹配伪元素，而现代 UI 库大量使用 ::before/::after 渲染边框、阴影、箭头等。IE9+、Firefox、Chrome 全部会因此出现微偏——比如按钮右侧多出 1px 空隙，或卡片圆角被伪元素边框切掉。
立即学习“前端免费学习笔记（深入）”；
正确写法必须显式包含：
*, *::before, *::after {
box-sizing: border-box;
}如果项目用了 Vant、Ant Design 或 Element Plus，还要额外补一句：
.van-button, .ant-input, .el-card__body {
box-sizing: border-box;
}- 避免用
!important强刷，优先靠 CSS 加载顺序控制权重 - 不要把这条规则包在
@supports或媒体查询里，X5 内核和旧 WebView 可能直接跳过 - Android ≤4.3 需补
-webkit-box-sizing，但 2026 年已基本可忽略
JS 尺寸逻辑怎么不跟着崩？
老代码里如果大量依赖 offsetWidth 判断容器是否足够宽，切换 border-box 后数值会突变：原来 width: 200px; padding: 10px; border: 2px 下 offsetWidth === 224，改完变成 200，可能导致折叠菜单误判、弹窗错位。
稳妥做法不是回退，而是做兼容桥接：
- 搜索全部
offsetWidth、clientWidth、getBoundingClientRect()使用点 - 对关键逻辑加注释，标明“此处假设 box-sizing: content-box”，方便后续收敛
- 新写的 JS 尺寸判断统一用
getComputedStyle(el).width+ 手动解析，或封装一个getBoxedWidth(el)函数，自动适配当前盒模型
修复后仍错位？重点查这三处
盒模型改对了，不代表布局就稳了。以下三点常被忽略，且和 content-box 遗留代码咬得很深：
-
margin永远不参与盒模型计算，但width: 100% + margin: 16px在小屏上照样触发横向滚动——它不是盒模型问题，但视觉表现一模一样 - 浮动布局中，
display: inline子元素（如未设display: block的span）在 IE11 下会无视box-sizing，回退到content-box行为 - rem 布局里，设计稿标注的 44px 高度是总高，但若某处
input漏了box-sizing，实际内容区只剩约 30px，文字就被截断——这不是字体问题，是盒模型没对齐设计意图
最隐蔽的点在于：改完 CSS 后，JS 逻辑可能仍在用旧尺寸做判断，而你从视觉上根本看不出异常。
