box-sizing: border-box会破坏旧项目隐式依赖content-box的布局逻辑：父元素width变总宽导致子元素width:100%计算基准收缩，表单控件在iOS/Android中渲染异常，JS尺寸读取含义改变但不报错，伪元素未重置引发装饰层错位。
box-sizing: border-box 会覆盖旧项目中隐式依赖 content-box 的尺寸计算
旧项目几乎都按 content-box 的逻辑写布局：比如给一个 .card 设 width: 300px; padding: 16px;，然后子元素用 width: 100% —— 这时子元素宽度是按父元素的 content 区（268px）算的。一旦全局加了 box-sizing: border-box，父元素的 width: 300px 就变成总宽，content 区缩到 268px，子元素 width: 100% 仍按这个新 content 宽算，结果比原来窄了，卡片内文字可能换行、图标错位、按钮被截断。
表单控件在 iOS Safari 和旧 Android WebView 中行为不一致
很多老项目没单独处理 input、textarea，直接靠浏览器默认渲染。但这些原生控件在不同系统里默认 box-sizing 值不同：
- iOS Safari ≤12 默认
content-box，且部分属性（如line-height、光标高度）与content-box强耦合 - Android 4.3 及更早 WebView 对
border-box支持不全，设了之后offsetHeight返回值异常 -
-webkit-appearance: none没同步加的话，select的下拉箭头区域仍按旧模型计算，点击热区偏移
JS 尺寸读取逻辑静默失效，但不报错
旧项目里大量用 element.offsetWidth 或 getBoundingClientRect().width 做定位、拖拽、弹窗居中。这些 API 返回值直接受 box-sizing 影响：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 原来是
content-box：返回的是 content 宽 + padding + border - 切到
border-box后：返回值不变，但含义变了——现在它等于你写的width值（含 padding/border） - 如果 JS 里写了
if (el.offsetWidth > 400) { ... }，而设计稿依据的是 content 宽，那判断就错了 - Canvas 绘图坐标映射、Tooltip 自动翻转检测、滚动容器高度计算，全会偏移几像素
伪元素 ::before / ::after 没被重置，导致装饰层错位
老项目常用伪元素画三角、阴影、遮罩，但伪元素不继承 box-sizing，默认仍是 content-box。全局只写 * { box-sizing: border-box; } 是无效的：
立即学习“前端免费学习笔记（深入）”；
.dropdown::after { content: ""; width: 0; height: 0; border: 5px solid transparent; border-top-color: #333; }- 这段代码在
content-box下，border 占空间；切到border-box后若没显式设伪元素的box-sizing，它的实际占位还是按旧逻辑膨胀 - 结果就是下拉菜单箭头位置飘移、卡片投影边缘漏出、渐变遮罩宽度不对
真正麻烦的不是改 CSS，而是旧项目里那些没写注释、没人维护的 JS 尺寸逻辑——它们不会崩溃，只是每天悄悄偏移 1~2px，直到某次发版后设计师指着屏幕说：“这个间距怎么不对？”
