浮动元素百分比宽度换行是确定性结果：总宽超父容器可用宽度（含亚像素舍入、box-sizing叠加、HTML空格间隙）即触发，参照父容器content box宽度计算，非总宽；根本解法是改用flex布局。
百分比宽度在浮动元素上“偶然”换行，不是计算失误，而是浏览器在亚像素渲染、盒模型叠加和HTML解析间隙共同作用下的确定性结果——只要总占用宽度超过父容器可用宽度，哪怕只多0.5px，就会触发换行。
浮动元素的百分比宽度参照谁计算
浮动元素设 width: 50% 时，这个百分比不是相对于父容器的总宽（含 padding/border），而是其 content box 宽度。如果父容器有 padding: 16px，那 content box 就比可视总宽少 32px；子元素再加 padding: 8px 和 border: 1px，实际占宽 = content 宽 + 16px + 2px → 必然超限。
更隐蔽的是：浮动元素脱离文档流后，父容器若未形成 BFC（比如没设 overflow: hidden 或 display: flow-root），它的高度会坍缩，导致某些浏览器对“包含块”的判定回退到视口，此时 width: 50% 实际按视口算，和预期完全脱节。
亚像素舍入在缩放时放大误差
当浏览器缩放为 125% 或 DPR 变化时，width: 33.333% 算出的像素值常带小数（如 375.67px），浏览器强制四舍五入取整（376px）。三个元素一累加，就可能比父容器多出 1–2px —— 这就是“偶然”换行的真实像素根源。
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools 的「Computed」面板查每个子项的
offsetWidth，加总后对比父容器的clientWidth，差值 > 0.5px 基本就是问题所在 -
calc(33.333% - 0.5px)在旧版 Chrome 中会被截断为calc(33.333% - 0px)，纯属无效写法 - 移动端
user-scalable=yes会让这个误差在每次捏合/拉伸中反复触发，错位更明显
HTML空格与 margin 叠加进一步吃掉可用空间
两个浮动 <div> 之间若有换行或空格，会被解析为一个文本节点，在默认 <code>font-size: 16px 下约占 4px；若又给每个元素设了 margin-right: 8px，右侧最后一个元素其实不需要这个右外边距，但样式没区分，等于白送 8px 给“空气”。
这些看似微小的开销加起来，轻松吞掉 10px 以上可用宽度：
- 写成紧凑 HTML：
<div></div> <div></div>，或对父容器设font-size: 0再对子项重置 - 避免左右都设 margin，改用
gap（需 flex）或只给左侧/中间元素设margin-right - 用
calc()扣减已知间隙：比如三列等宽 + 左右各 8px margin，写成width: calc(33.333% - 10.666px)
为什么 clear 和 min-width 都压不住换行
clear: both 是让当前元素避开上方浮动，不改变浮动元素自身的排列逻辑；min-width 设在子元素上只约束它自身最小宽度，对是否被“挤下去”毫无影响——换行决策发生在布局阶段，依据的是所有浮动项的 border-box width 总和 vs 父容器可用宽度。
真正起作用的只有三件事：
- 全局设
* { box-sizing: border-box }，让width指代最终占位宽度 - 父容器设合理
min-width（必须手算：所有子项offsetWidth之和 + 10–20px 余量） - 彻底绕开 float：用
display: flex+flex-wrap: wrap，宽度计算天然适配缩放，无需手动清浮动、扣 margin、防亚像素
复杂点在于：就算你把 box-sizing、calc、min-width 全配齐，只要还在用 float，就始终要和 HTML 解析、DPR 变化、字体渲染这些底层机制搏斗——这不是调参能根治的问题，是架构选择问题。
