Retina屏float布局缝隙源于devicePixelRatio下亚像素渲染失准，需从整数尺寸、合成层和baseline对齐三方面解决：强制整数height/line-height/font-size、用transform:translateZ(0)启GPU合成、修正vertical-align基线。
直接用 float 布局在 Retina 屏上出缝隙，不是你 CSS 写错了，而是浏览器在 devicePixelRatio = 2 或 3 下对非整数逻辑像素做亚像素插值时暴露的底层渲染限制。清除浮动、加 overflow: hidden 都压不住——得从尺寸精度、合成层、baseline 对齐三路下手。
为什么 clear: both 清不掉缝隙
缝隙根源不是父容器塌陷，而是浮动元素脱离文档流后，其底部与文字行框的 vertical-align: baseline 计算失准。哪怕没显式写这行，内联上下文里它也默认生效。尤其当浮动项含图片或文字时，基线会卡在字体 descender 位置，留出不可控空隙。
- 用 DevTools 检查浮动元素的
getBoundingClientRect().bottom和相邻文字行的line-height顶部，差值常为0.3px～0.7px这类非整数值 -
clear: both只让当前元素退出浮动流，不干预后续内容的 baseline 对齐逻辑 - 给父容器加
display: flow-root能强制包裹，但若内部尺寸本身是小数（如height: 20.5px），仍会触发 sub-pixel 渲染
浮动子项必须用整数尺寸 + 禁用系统缩放
Retina 屏下，font-size: 16px 在 iOS「更大字体」开启时可能被系统渲染为 18.2px，连带 line-height、padding 全部失准。必须切断这个链路。
- 所有浮动子项的
height、line-height、font-size必须是整数（如20px，不能是20.5px） - 父容器加
text-size-adjust: none，防止 iOS/macOS 自动放大文本 - 避免用百分比高度（如
height: 50%），它依赖父容器计算，容易产出小数结果 - 若需响应式，改用
clamp(20px, 4vw, 24px)，确保最终值经浏览器计算后仍是整数
伪元素边框 + transform: scaleY() 替代 border
直接写 border: 1px solid #ccc 在 DPR=2 下占 2 物理像素，边缘抗锯齿后发虚；用伪元素画线再缩放，才能落到 1 物理像素上。
立即学习“前端免费学习笔记（深入）”；
- 父元素必须设
position: relative，否则::after的position: absolute会脱标到body - 伪元素用
height: 1px+background-color，别用border-bottom（受box-sizing和line-height干扰） -
transform: scaleY(0.5)+transform-origin: 0 100%（写全，Safari 不认bottom关键词） - 务必加
pointer-events: none，否则安卓 WebView 可能拦截点击
最后一步：强制 GPU 合成层 + 抑制插值
translateZ(0) 不是为了动画，而是告诉浏览器：“这个区域要单独建合成层”，让渲染器以 device pixel 为单位重绘边界，绕过主渲染线程的亚像素取整逻辑。
- 在浮动容器上加
transform: translateZ(0)，不是子项上 - 搭配
will-change: transform预分配资源，旧版 Chrome（≤95）除外，它可能抖动 - 检查 DevTools 的 Layers 面板：若没看到新增图层，说明被父级
overflow: hidden截断或z-index覆盖了 - 若已用
rotate()等 transform，直接追加translateZ(0)即可，不用重复声明will-change
真正难搞的是那些隐式干扰项：比如父容器一个未重置的 font-size、一行没删的空格、甚至 <img alt="CSS浮动元素在Retina屏幕产生像素缝隙怎么修？" > 的默认 vertical-align，都会在 DPR=2/3 下被放大成可见缝隙。调试时别只盯着浮动元素本身，用 Show Rasterization Borders 看半透明描边，才是确认 sub-pixel 渲染是否激活的铁标准。
