浮动布局在不同DPI屏幕下断行是百分比计算、亚像素渲染与浏览器取整策略叠加的必然结果；DPR=2时50%计算为375.3px被截为375px，两列少1px触发换行，开发机（DPR=1）无法复现。
浮动布局在不同DPI屏幕下断行，根本不是“没清浮动”或“宽度写错了”，而是百分比计算 + 亚像素渲染 + 浏览器取整策略三者叠加导致的必然结果。DPR=2时，width: 50%算出来是375.3px，渲染强制截为375px；两列加起来就少1px，直接触发换行——这在开发机（DPR=1）上完全看不到。
为什么width: 50%在Retina屏上会断行
浏览器对浮动元素的宽度做 layout 计算时，用的是逻辑像素（CSS px），但最终绘制到物理屏幕上要乘以 window.devicePixelRatio。当计算结果带小数（如50% → 375.3px），不同引擎对 sub-pixel 的处理策略不一致：
- Safari WebKit 倾向向下取整（375px），Chrome Blink 可能四舍五入（375px 或 376px），造成左右列总宽不稳定
- 若父容器有
border或padding，而子项未设box-sizing: border-box，实际占用宽度会进一步溢出 -
float: left本身不参与 flex/grid 那样的弹性重排，断行后无法自动回流，卡死在第二行
用calc()预留容错空间而非硬写50%
直接替换所有width: 50%为带边框/间距容错的表达式，避免小数累积：
.col {
float: left;
width: calc(50% - 1px); /* 留1px给border或间隙 */
box-sizing: border-box;
}- 若列间需1px分隔线，用
margin-right: 1px+ 最后一项margin-right: 0，比靠减法更可控 - 禁用
font-size继承干扰：父容器设font-size: 16px，子项显式重置，防止 iOS「更大字体」导致实际计算值非整数 - 不要用
99.9%这类临界值——缩放时小数部分波动更大，calc(50% - 0.5px)同样危险，必须是整数物理像素容错
真正该停用float的场景
只要涉及缩放、DPR变化或响应式断点，float 就是过时模型。现代替代方案不是“优化”，而是绕开：
立即学习“前端免费学习笔记（深入）”；
-
display: flex+flex-wrap: wrap：缩放时自动重算主轴尺寸，无亚像素断行风险 -
display: grid+grid-template-columns: repeat(auto-fit, minmax(300px, 1fr))：浏览器内部用 device pixel 对齐栅格，天然抗DPR抖动 - 必须兼容 IE10？用
@supports (display: grid)降级，但测试重点必须放在 iOS Safari —— 它的 zoom 行为和 Chrome 完全不同，且不支持subgrid
最易被忽略的一点：断行问题往往只在真机双指缩放时暴露，DevTools 模拟 DPR 不会触发真实 layout 重排。上线前务必用 window.devicePixelRatio 打印当前值，并打开 Safari 的 “Show Rasterization Borders” 看是否出现半透明描边——那是亚像素渲染已激活的铁证。
