<p>box-sizing: border-box 是唯一可靠方案，它使 width/height 包含 padding 和 border；需全局设置 { box-sizing: border-box; } 并补充 :before, *:after { box-sizing: inherit; }，注意 table 元素需单独声明，且 transform 和 JS 尺寸读取存在兼容性差异。</p>
直接设 box-sizing: border-box 就能解决——这是唯一可靠、可预测的方案，其他绕弯子（比如用负 margin 抵消 padding）都会引入新问题。
为什么 padding-right 会让盒子变宽
默认是 content-box 模式：元素的 width 只管内容区，padding-right 和 border 都额外加在右边。比如 width: 200px + padding-right: 10px + border-right: 2px，实际占位就是 212px。
- 这种计算方式在响应式布局里极易导致父容器溢出或换行
-
padding-right的百分比值仍基于父元素宽度，但叠加后总宽不可控 - Flex/Grid 容器中，子项因 padding 撑开宽度，可能破坏对齐或收缩行为
box-sizing: border-box 的实际写法
不是只给某个元素加，而是要统一作用域内所有元素，否则局部设置反而更难维护。
- 全局生效（推荐）：
* { box-sizing: border-box; }注意：IE8+ 支持，无需前缀；但*:before和*:after也需显式继承，可加*:before, *:after { box-sizing: inherit; } - 局部重置（慎用）：如果第三方组件强制用了
content-box，可用更高优先级覆盖，例如.my-card > * { box-sizing: border-box; } - 不建议只设单个方向：
box-sizing是整体盒模型开关，无法“只让 padding-right 不撑开”，它影响的是整个 width/height 的计算逻辑
常见踩坑点
很多人以为加了 border-box 就万事大吉，其实有三个隐蔽雷区：
立即学习“前端免费学习笔记（深入）”；
-
table元素默认忽略box-sizing，需单独加table { box-sizing: border-box; }才生效 - 使用
transform: scale()后，视觉尺寸变了，但box-sizing计算仍按原始尺寸，可能导致布局错位 - JavaScript 读取
offsetWidth时返回的是渲染后总宽（含 padding/border），但getComputedStyle(el).width返回的是 CSS 设置值——两者在border-box下数值一致，在content-box下不一致，容易误判
真正麻烦的从来不是怎么写这行 CSS，而是团队协作时有人漏掉全局重置，或者在已有 content-box 基础上临时加 border-box 却没检查子元素是否继承——结果是布局一半准、一半飘。
