移动端盒模型“坑”源于默认 content-box，width/height 仅含内容区，padding/border 额外增加导致撑破容器；必须全局设 border-box 并覆盖伪元素及第三方组件，否则 rem 布局与设计稿脱节。
为什么移动端总被盒模型“坑”？
因为默认 box-sizing: content-box，你写的 width: 100px 只算内容区，padding 和 border 额外加进去——在小屏上直接撑破容器、触发横向滚动。iOS Safari 和 Android Chrome 全部默认如此，不是 bug，是标准行为。
设计师给的按钮高 44px，指的是“整体高度”，但你写 height: 2.75rem（按 1rem=16px 算），若没改盒模型，实际内容区只剩约 36px，按钮就“瘦了”。这不是 rem 翻车，是盒模型没对齐设计意图。
必须全局设 box-sizing: border-box 的实操细节
别只写 * { box-sizing: border-box } 就完事——伪元素和第三方组件常被漏掉：
- 加上
*::before, *::after { box-sizing: border-box }，否则button::after这类装饰元素仍按content-box计算 - Vant/NutUI 等 UI 库内部可能重置过
box-sizing，得单独补一句.van-button, .nut-button { box-sizing: border-box } - 避免用
!important强覆盖，优先在 CSS 加载顺序里靠前声明
rem 布局里盒模型错位的典型表现和修复
现象：按钮文字被截断、输入框光标偏移、栅格列宽忽大忽小——大概率是 box-sizing 没统一，导致 rem 值对应的实际像素和设计稿脱节。
立即学习“前端免费学习笔记（深入）”；
关键点：
- 设计稿标注的尺寸（如卡片宽 340px）是包含
padding和border的总宽，必须用border-box才能直接映射为width: 21.25rem（340 ÷ 16） - 如果某处漏了
box-sizing，比如input元素仍用默认值，哪怕根字号算对了，height: 2.75rem也会比预期矮出2px边框 +8px内边距 - 检查 computed 样式里的
width和border-box width是否一致，不一致说明盒模型没生效
容易被忽略的兼容性陷阱
旧版安卓 WebView（4.3 及更早）根本不认 box-sizing 属性，写了等于白写。这时候必须靠降级策略：
- 对关键容器（如按钮、表单控件）额外加
width: calc(100% - 16px)手动扣掉内边距和边框，绕过盒模型解析 - 避免在
flex子项上同时用width和flex-basis，旧内核会优先按width渲染，导致box-sizing失效 - 微信 X5 内核偶尔会忽略全局通配符，建议把
box-sizing声明拆到基础重置 CSS 的第一行，且不嵌套在@supports或媒体查询里
盒模型本身不耗性能，但错配后引发的重排、横向滚动、软键盘遮挡等问题，才是真正卡顿的源头。适配不是堆技巧，而是让每个尺寸声明都明确对应“它到底想占多大物理空间”。
