盒模型默认为 content-box，width 仅控制 content 区域，加 padding/border 会导致总宽度超出预期；应优先检查 box-sizing 是否生效并统一设为 border-box。
盒模型默认是 content-box，不是你看到的“整个盒子”
很多开发者误以为设置 width: 300px 就等于元素占满 300px 宽度，但实际它只控制 content 区域。一旦加了 padding 或 border，总宽度就变成 width + padding-left + padding-right + border-left + border-right——这正是溢出的根源。
- 检查目标元素是否没显式声明
box-sizing，浏览器 默认用content-box - 用开发者 工具（F12）选中元素，看右侧面板的“Computed”里
box-sizing值；再对比“Layout”中的width、padding、border和最终“Total width” - 若父容器宽度固定（如
max-width: 800px），子元素哪怕写width: 100%，只要带 padding/border，也会撑破
排查时优先验证 box-sizing: border-box 是否生效
加 box-sizing: border-box 是最直接的修复手段，但它不是万能的——必须确保它真被应用了，且没被更高优先级规则覆盖。
- 在 CSS 中写
* {box-sizing: border-box;}是常见做法，但注意：它不作用于svg、input[type="range"]等替换元素，也不影响table相关元素的默认行为 - 检查是否有更具体的规则（比如
.card {box-sizing: content-box;}）意外重置了它 - 某些 CSS 重置库（如 Normalize.css）不修改
box-sizing，而某些 UI 框架（如 Bootstrap）会全局设为border-box，混用时容易冲突
*, *::before, *::after {box-sizing: border-box;}flex / grid 容器中 width: 100% 不等于“填满可用空间”
在 Flex 或 Grid 布局里，width: 100% 是相对于其包含块（containing block）计算的，而这个包含块可能受 flex-basis、min-width 或网格轨道尺寸限制，导致实际渲染宽度异常。
- 对 flex 项目，优先查
flex-basis（默认为auto）和flex-shrink（默认为 1）——即使写了width: 100%，它也可能被压缩或拉伸 - 用开发者工具看元素的“Flex”面板，确认
Base size和Final size是否一致 - Grid 项若设了
width: 100%但所在轨道用fr或max-content定义，该 width 可能被忽略；此时应改用justify-self: stretch或直接依赖网格自动填充
overflow: hidden 不是解决方案，只是掩盖问题
加 overflow: hidden 能让滚动条消失、内容被裁剪，但它不解决根本的尺寸错配。后续维护中，这个“隐藏的溢出”可能在响应式断点、字体加载、动态内容插入时突然暴露。
立即学习 “ 前端免费学习笔记（深入）”；
- 如果靠
overflow: hidden勉强显示，说明盒模型或布局逻辑存在未识别的矛盾 - 尤其注意 伪元素 （
::before/::after）或 绝对定位 子元素——它们脱离文档流，但若设置了宽高 +padding，仍可能造成父容器高度塌陷或意外撑开 - 用
outline: 1px solid red临时标出所有元素边界，比依赖视觉判断更可靠
真正卡住人的，往往不是哪个属性写错了，而是多个盒模型规则在不同上下文里叠加生效——比如一个用了 border-box 的组件，嵌进某个 display: table-cell 的老布局里，又碰上字体加载导致行高变化，这时候光看 CSS 文件根本看不出问题。
