box-sizing: border-box 能防止 padding 和 border 撑开宽高，但仅设置该属性不保证生效；必须全局覆盖所有元素及伪元素（, ::before, *::after），并验证目标元素实际计算值是否为 border-box。
直接设 box-sizing: border-box 就能防止 padding 和 border 撑开元素宽高，但光写这一行不保证生效——真正起作用的前提是它被正确继承、没被覆盖、且用在了该起效的场景里。
为什么写了 box-sizing: border-box 还是撑开了？
常见错误不是属性写错，而是它根本没落到目标元素上：
- 选择器优先级太低：比如只对
.card设了box-sizing: border-box，但某个更具体的.card input规则里又写了box-sizing: content-box，后者就赢了 - 伪元素漏掉：
* { box-sizing: border-box; }不管::before和::after，它们仍按默认content-box算，可能造成视觉错位 - 动态插入的元素没继承：JS 里
document.createElement('div')创建的节点，不会自动带父级的box-sizing，除非父容器设了inherit且自己没重置 - 表单控件“硬编码”：某些旧版 Safari 或 IE 中，
input、textarea默认忽略继承，必须显式声明input { box-sizing: border-box; }
全局启用 box-sizing: border-box 的稳妥写法
别只靠 * { box-sizing: border-box; }。现代项目推荐这个组合，覆盖所有边界情况：
html {
box-sizing: border-box;
}
*, *::before, *::after {
box-sizing: inherit;
}
这样做的好处：
-
html元素设为border-box，确保根级基准一致 -
*和两个伪元素选择器一并inherit，避免漏掉任何渲染节点 - 后续组件库或第三方 CSS 即使覆盖了某条规则，只要没加
!important，继承链仍有效 - 比单纯通配符性能更好（浏览器对
inherit有优化）
box-sizing: border-box 在 flex/grid 布局中是否还重要？
非常重要，而且影响更隐蔽：
- flex 子项即使设了
flex-basis: 33%，只要它自身有padding: 12px且仍是content-box，实际占用宽度 = 33% + 24px，导致三列无法并排 - grid 中
grid-template-columns: 1fr 1fr下，若子项width: 100%+padding，内容区会溢出轨道，触发滚动或裁剪 - 关键点：flex/grid 控制的是“分配空间”，但每个子项内部怎么瓜分这块空间，仍由
box-sizing决定 - 结论：不设
border-box，再精细的布局容器也救不了子项内部的尺寸失控
哪些地方最容易忘记加 box-sizing: border-box？
不是容器，而是那些“看起来不需要”的小东西：
-
img：部分 UI 库或 reset.css 没重置它，加上max-width: 100%后再加padding，照样撑破 -
button：自带边框和内边距，尤其在移动端点击区域计算时，尺寸偏差会导致热区错位 - 自定义 SVG 图标包裹层：常写
width: 24px; height: 24px;，但忘了加padding或border后实际变大 - CSS-in-JS 场景：scoped 样式或 emotion/styled-components 中，如果没把
box-sizing提到全局 theme 或 reset，容易各写各的
最易被忽略的其实是“生效验证”——别只看代码有没有写，打开 DevTools 的 Computed 面板，直接查目标元素的 box-sizing 值和 Metrics 里的 Total width 是否随 padding 变化而恒定。这是唯一靠谱的判断方式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
