浮动元素实际占位宽度=width+左右padding+左右border+左右margin；哪怕超1px即换行，需用box-sizing:border-box控制子项、calc()扣减所有边距、确保父容器形成bfc并清理html空白。
浮动元素总宽度怎么算才不溢出
浮动元素的「实际占位宽度」不是你写的 width 值，而是：width + padding-left + padding-right + border-left + border-right + margin-left + margin-right。哪怕只多出 1px，浏览器就会把它硬挤到下一行——这就是“掉队”或横向滚动条出现的根源。
常见错误现象：float: left 的导航项设了 width: 25%，四等分却换行；小屏下突然出现横向滚动条，Computed 样式里每个子项加起来明明是 100%。
- 父容器若有
padding: 16px，它的 content 宽度就比总宽少 32px，子元素width: 100%只能拿到这个缩水值 - 子元素自己再加
padding: 8px和border: 1px，实际占宽 = content 宽 + 16px + 2px → 必然超 - HTML 源码中两个浮动
<div> 之间有换行或空格，会被解析为约 4px 的文本节点间隙（<code>font-size: 16px下）box-sizing: border-box 为什么不能一键解决
box-sizing: border-box只管住子元素自身的盒模型：把padding和border吸进width里。但它对父容器的padding和border完全无感——而浮动元素的100%是按父容器的 content 区计算的。所以即使所有子项都写了
box-sizing: border-box，只要父容器有padding，它们依然会溢出。- 全局
* { box-sizing: border-box }是基础，但不等于万能；框架或重置样式可能覆盖它 - 临时调试时给父容器加
outline: 1px solid red，一眼看出子元素是否“凸出来” - 检查 computed 样式里的
box-sizing值，别信 CSS 文件里写了就生效
float + calc() 动态算宽的坑在哪
用
calc()算浮动宽度（比如width: calc(25% - 24px)）看似聪明，但必须同步处理所有影响宽度的变量，否则照样溢出。典型误用：只减去 margin，却忘了父容器 padding 或子元素自身 border。
- 列间间隙必须用
margin-right，不能用padding，否则会影响 float 排列逻辑 - 如果父容器设了
border: 2px，calc(25% - 24px)还得再减 2px 才准（按比例摊到每项） - 响应式断点切换时，
calc()表达式没跟着改，小屏下 margin 没缩，宽度直接爆掉
为什么 overflow: hidden 能“修复”溢出但不治本
给父容器加
overflow: hidden常被当作清浮动方案，但它只是触发 BFC，让父容器能“看见”浮动子元素并撑高——同时把横向溢出内容裁掉。视觉上不滚动了，但元素实际还是超了，只是被藏起来了。更隐蔽的问题：它会裁掉
position: absolute子元素的阴影、下拉菜单、tooltip 等溢出部分。- 真正要防溢出，得从源头控制总宽度，而不是靠裁剪掩盖
- 若必须用浮动，优先用
display: flow-root触发 BFC（IE 不支持），或伪元素清除（::after+clear: both） - Flex/Grid 下浮动失效，但嵌套浮动仍存在——比如父是
display: flex，子是普通块，子再float，这时宽度计算逻辑照旧
浮动布局里最易被忽略的，是「父容器是否形成 BFC」和「HTML 源码中看不见的空白字符」——这两者不会报错，但会让所有宽度计算全部跑偏。
- 全局
