<p>移动端必须全局重置 box-sizing 是因为默认 content-box 导致 width 加 padding 和 border 后溢出窄屏；需用 , ::before , *::after { box-sizing: border-box; } 并显式设置表单控件，否则伪元素和 input 等仍按 content-box 计算，引发布局错乱与 JS 尺寸读取偏差。</p>
直接设 box-sizing: border-box 就能改掉移动端盒模型的默认计算逻辑，但漏掉伪元素或表单控件，布局立刻出错——这不是兼容性问题，是尺寸计算被悄悄绕过了。
为什么移动端必须全局重置 box-sizing
移动端屏幕窄、并排元素多（比如两栏卡片、输入框+按钮），浏览器默认用 content-box：你写 width: 50%，再加 padding: 12px 和 border: 1px，实际宽度就变成 50% + 24px + 2px，直接溢出父容器。设成 border-box 后，width: 50% 就真等于“占一半”，内边距和边框自动往里缩。
常见错误现象：
- 两个
width: 50%的盒子在 Flex 容器里换行 -
overflow: hidden压不住横向滚动条 - iOS Safari 下
input光标错位、高度塌陷
*、*::before、*::after 必须一起写
伪元素不继承父级 box-sizing，默认仍是 content-box。你写了 * { box-sizing: border-box; }，但 ::before 画的下拉箭头、遮罩层、装饰边框仍按内容宽 + padding + border 算，结果就是容器看着没溢出，实际内部撑开 2px，导致换行、定位偏移、滚动条意外出现。
立即学习“前端免费学习笔记（深入）”；
正确写法（且必须放在所有自定义样式之前）：
*, *::before, *::after {
box-sizing: border-box;
}容易踩的坑：
- 只写
*，漏掉伪元素——DevTools 里检查::before的 computedbox-sizing，会发现它确实是content-box - 这条规则被后续样式覆盖——顺序不对，等于白写
- 第三方 UI 库（如 Vant）用
!important强制content-box，得单独覆盖其选择器
表单控件必须显式声明 box-sizing: border-box
input、textarea、select 在不同浏览器中默认值不一致：input[type="search"] 在 Safari 中默认是 content-box，哪怕父级设了 border-box 也不生效；某些安卓 WebView 中 textarea 仍按 content-box 渲染。
实操建议：
- 对所有表单控件显式声明，不要依赖继承：
input, textarea, select, button { box-sizing: border-box; } - 旧版 Safari（≤12）和部分 Android WebView 需加
-webkit-appearance: none缓解渲染异常 - 搭配
height或line-height使用时，注意border-box下高度包含 padding 和 border，别再按老习惯留空余
box-sizing 切换后 JS 尺寸读取逻辑会静默变化
切换到 border-box 后，element.offsetWidth、getBoundingClientRect().width 返回的是“含 padding + border”的总宽，不再是 content-box 下的纯内容宽。这不会报错，但会让依赖尺寸的逻辑跑偏。
重点检查：
- Tooltip 自动翻转判断（基于元素宽度做方向决策）
- 弹窗居中计算（用
offsetWidth算 left 偏移） - 拖拽缩放比例（Canvas 坐标映射依赖真实宽高）
调试技巧：临时禁用全局 box-sizing 规则，在 DevTools 里对比 offsetWidth 值变化；避免在 CSS 动画中动态切换——对它无效，只会触发 layout thrashing。
真正麻烦的不是加那三行 CSS，而是加完之后没人去查 JS 里那些隐式依赖 content-box 的尺寸计算。尤其当设计稿给的是“视觉宽度”，而代码读的是 offsetWidth，偏差就藏在毫厘之间。
