根本原因是高dpr下百分比宽度亚像素计算后强制取整，浮动布局逐个放置且无抗锯齿缓冲，导致误差累积；应改用flex或grid并重置float:none。
浮动元素缩放时出现碎像素间隙的根本原因
这不是 CSS 写错了，而是浏览器在高 DPR（设备像素比）下对 width: 50% 这类百分比值做亚像素计算后强制取整导致的——比如视口宽度为 750.6px，50% 算出来是 375.3px，但渲染层只能画整数像素，于是四舍五入成 375px；两列加起来就少 1px，触发换行或边缘露白。
关键点在于：浮动布局依赖文档流中“逐个放置 + 绕行”的旧机制，它不预留抗锯齿缓冲，也不参与现代合成层调度，所有尺寸计算都在主渲染线程完成，缩放时无法动态重平衡。
- 该问题在 iOS Safari（
user-scalable=yes）、Chrome 移动版缩放手势下高频复现 - 仅靠
box-sizing: border-box或clear: both无法修复，它们不干预宽度计算路径 - 使用
transform: scale()模拟缩放会绕过此问题，但会放大整个渲染层，影响点击精度
为什么 will-change: transform 单独加无效
will-change: transform 只是提示浏览器“可能要变”，但浮动元素（float: left）默认不在合成层里，没有实际触发 transform 属性，浏览器大概率忽略该声明。
真正起作用的是组合：必须同时存在 transform: translateZ(0)（强制创建 GPU 合成层）+ will-change: transform（预分配资源）。缺一不可。
- DevTools 的 Layers 面板里看不到新增图层？说明
translateZ(0)没生效，检查是否被父级overflow: hidden截断或被z-index覆盖 - 旧版 Chrome（≤95）在浮动上下文中对
will-change行为不一致，可能引发抖动而非修复 - 如果元素已有
rotate(15deg)，直接追加translateZ(0)即可，不必额外加will-change
浮动 + 百分比宽度在缩放时为何比 flex 更脆弱
浮动布局把尺寸决策权交给了每个子元素独立计算，而 flex 容器由主轴统一调度剩余空间。当缩放发生时：
- 浮动：每个
width: 50%单独算、单独取整，误差累积 → 两列总宽 ≠ 100% - flex：
flex: 1是按容器可用空间实时均分，即使单个子项宽度算出 375.3px，渲染器仍可将其作为逻辑单位参与对齐，不强制截断 - 浮动还受父容器
font-size、line-height、border等隐式样式干扰，flex 则完全隔离这些影响
更麻烦的是：哪怕只在一个侧边栏模块里用浮动，它对相邻段落中的空格、<img> 的基线对齐仍有连锁影响，在 Retina 屏上会被放大成亚像素偏差。
真正该做的不是“修浮动”，而是“绕开浮动”
现在 display: flex 和 display: grid 在 Safari 15.4+、Chrome 88+、Firefox 66+ 全平台稳定支持，连清除塌陷都只需 display: flow-root —— 它比 overflow: hidden 安全，不会裁剪阴影或下拉菜单。
迁移时最容易被忽略的点是：旧代码里的 float: left 不会自动失效。只要子元素还挂着 float，浏览器就优先执行浮动规则，再套 flex 排列，结果就是错位、换行失效、justify-content 失效。
- 必须显式重置：
float: none - IE10/11 需补
-ms-flex: 1，否则flex: 1不生效 - 若项目需兼容 IE9 及以下，别强行改 flex，老老实实用
box-sizing: border-box+::after清浮动兜底
碎像素间隙背后不是渲染 bug，而是浮动这个 1998 年的设计在 2026 年继续被当作布局工具所付出的代价。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
