浮动元素最后一行掉下是因浏览器对百分比宽度四舍五入导致总宽超1px，非clear或空格所致；修复可用float:right、margin-right:-1px或改用flex/grid布局。
直接给最后一个浮动元素加 margin-right: -1px，或把它改成 float: right，基本就能止住掉行——不是它“不听话”，而是浏览器对小数宽度四舍五入后，总宽悄悄超了 1px。
为什么 float 元素总在最后一行掉下去
这不是 clear 没加对，也不是 HTML 空格惹的祸（虽然那也会导致错位），而是浏览器在计算 width: 25% 这类百分比时，会把结果四舍五入到最近的像素。比如父容器宽 1000.6px，25% 就是 250.15px → 四舍五入成 250px；但四个 250px 加起来只有 1000px，剩下 0.6px 被“攒”在某个元素上，最终某一个实际渲染宽度变成 251px，整行就超了。
这种误差在 rem/em、缩放、高 DPI 屏下尤其明显，且旧版 Chrome 和 Firefox 对 calc() 的处理更不稳定。
- 用 DevTools 的 “Computed” 面板看每个元素真实
width值，别信 Styles 里写的值 - 检查是否漏了
box-sizing: border-box：没设的话，padding和border会额外加进宽度 - 避免混用
calc(25%) + margin-right: 8px，优先写成width: calc(25% - 2px)
快速修复：改 float 方向或微调 margin
最轻量、兼容性最好的解法，是绕开“从左到右累加宽度”这个脆弱逻辑：
- 把最后一个元素设为
float: right，其余保持float: left——它自动贴右，不参与左浮序列的宽度累计 - 或者统一给所有浮动项加
margin-right: -1px（仅最后一项）或width: calc(25% - 1px) - 别写
width: 24.9%：浏览器可能对 24.9% 再次四舍五入，反而更不准 - 如果用了
rem单位，缩放时误差会被放大，此时px反而更稳
为什么 clear: both 不管用
clear: both 的作用对象是「它自己」，不是前面的浮动元素。你给最后一个浮动项加 clear: left，只会让它强制换行，加剧掉队；在父容器末尾加个 <div style="clear:both"></div>，只是拦住后续内容，对浮动块之间的排列毫无影响。
真正起效的清除动作，必须落在最后一个浮动元素之后、且是文档流中第一个块级位置——比如父容器的 ::after 伪元素，或直接设 display: flow-root。
-
clear不修“掉行”，只防“上浮” - 给浮动子元素自己加
clear是常见误操作，等于主动把它踢出当前行 - 现代项目中，
display: flow-root比overflow: hidden更干净，不意外裁剪阴影或position: absolute子元素
该换布局模型了
浮动本不是为网格布局设计的，它是为图文环绕服务的。你花半天调 margin-right 和 calc()，不如三行 CSS 切到 display: flex 或 display: grid：
-
flex-wrap: wrap下，宽度由容器统一分配，不再依赖单个元素宽度累加 -
grid-template-columns: repeat(4, 1fr)天然支持等宽列，最后一行自动左对齐，无计算误差 - IE10+ 支持
flex，IE11+ 支持grid，老项目兜底也比硬修 float 成本低 - 如果子元素已写死
float，但父容器设了display: flex，那float属性会被浏览器忽略（控制台会警告）
真正容易被忽略的是：掉行不是 bug，是 float 在按规范工作；而你试图用它做精确栅格，才是问题起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
