因为浮动布局中参与并排计算的是子元素而非父容器，父容器的box-sizing只影响自身宽高解析，不控制子元素占位；必须对所有浮动子元素显式设置box-sizing:border-box，并清除浮动、合理计算margin与width总和。
为什么只给父容器设 box-sizing: border-box 不管用
浮动布局里真正参与并排计算的是子元素，比如多个 .item，不是父容器。父容器的 box-sizing 只影响它自己宽高的解析逻辑，跟子元素怎么占位毫无关系。
常见错误现象：父容器加了 box-sizing: border-box，但子项仍因 padding 和 border 撑出设定宽度，导致换行或错位。
- 必须对所有浮动子元素显式设置
box-sizing: border-box，哪怕它们样式来自不同选择器 - 全局重置最稳妥：
* { box-sizing: border-box; }，但要确保它在所有样式表最前面加载 - 若用组件库（如 Ant Design、Element UI），检查其内部是否覆盖了该规则——有些库会重置为
content-box，得针对性再覆盖
box-sizing: border-box 配合浮动时的三个硬约束
设了 border-box 只是前提，不是终点。浮动排列稳定还需满足三件事：
- 所有浮动子项的
width值加起来不能超 100%，且必须把margin算进去（box-sizing不管margin） - 父容器必须能“看见”浮动子项的高度，否则百分比宽度按塌陷后的 0 计算——得用
display: flow-root或::after清除浮动 - 避免在浮动子项上混用
width和flex相关属性（如flex-basis），浮动下这些属性被忽略，但开发者可能误以为生效，导致调试错乱
缩放时突然错位，大概率是 box-sizing: content-box 在作祟
缩放本身不改变 CSS 计算逻辑，但它会放大 sub-pixel 渲染误差。当浮动元素用默认 box-sizing: content-box 时，width: 50% + padding: 8px + border: 1px 的实际总宽 ≈ 50.03%，缩放后被四舍五入为 51% 或 49%，右侧元素就掉行了。
- 只给子元素加
box-sizing: border-box不够——父容器如果有padding，它的可用宽度已缩减；若父容器仍用content-box，子元素按 100% 算出来的宽度还是会溢出 - 触发条件明确：浮动 + 百分比宽度 + 任意
padding/border+ 缩放操作 - Chrome DevTools 的 “Toggle device toolbar” 模拟缩放也复现此问题，不单是用户手动缩放
浮动换行异常，别只盯着 width 算术和
几个 float: left 的盒子并排后最后一个掉行，但用开发者工具看每个盒子的 width、padding、border 加起来又没超——问题大概率出在盒模型计算被忽略，或父容器高度塌陷导致后续布局失准。
- 检查父容器是否设置了
overflow: hidden、display: flow-root或自身float，否则浮动子元素会脱离文档流，父容器高度塌陷 - 若内容含长单词、URL 或连续无空格字符串，
word-break: normal（默认值）会让整段内容强行撑开容器，需加word-break: break-word或overflow-wrap: break-word - 清除浮动后仍意外换行？常见原因是清除元素自身也参与了浮动流，或清除位置不对（比如插在浮动元素中间而非末尾）；推荐伪元素法：
.clearfix::after { content:""; display: table; clear: both; }
真实项目里最容易被忽略的，是伪元素 ::before 和 ::after 默认不继承 box-sizing: border-box。很多清浮动代码、图标、UI 库内部都依赖它们，一旦它们仍走 content-box，就会偷偷多占空间，导致整体偏移。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
