translate(-50%, -50%) 在 Retina 屏下必糊，因其基于父容器尺寸动态计算出的偏移值常为半像素（如384.5px），触发浏览器亚像素插值渲染，而Retina屏将0.5px偏移放大为2物理像素模糊带。
为什么 translate(-50%, -50%) 在 Retina 屏下必糊
因为 -50% 是相对父容器尺寸动态计算的，而父宽高在 DPR=2 时虽为偶数物理像素，但除以 2 后极易产生半像素偏移。例如父容器宽度为 769px，top: 50% 得到 384.5px，transform: translateY(-50%) 就是 -384.5px —— 浏览器必须对亚像素位置做插值渲染，文字和边框立刻发虚。
Retina 屏本身不“导致”模糊，它只是把亚像素问题放大了：1 个 CSS 像素 = 4 个物理像素，0.5px 偏移就变成 2 物理像素的模糊带。
- 用
getBoundingClientRect()打印实际left/top值，看是否含小数 - 固定宽高的容器（如
width: 400px）比100vw更易控制像素对齐 - 避免在 modal、tooltip 等频繁进出视口的
position: absolute元素上依赖百分比 transform
translateZ(0) 能不能修复模糊
translateZ(0) 不能一概而论。它有时让文字变清晰，但本质是“碰巧触发了更优光栅化”，不是修复根源；反而可能加重内存占用或滚动卡顿。
原因在于：translateZ(0) 强制创建新合成层，把元素交给 GPU 单独渲染。GPU 渲染时若恰好落在整数像素坐标上，抗锯齿减弱，看起来更锐利；但若原始 transform 计算结果仍是 translate(-50.3px, 20.7px)，GPU 仍得插值——模糊照旧。
立即学习“前端免费学习笔记（深入）”；
- 只对已启用硬件加速的元素起作用（
position: absolute+transform通常满足） - 在 Safari 上效果不稳定，iOS 更明显；Chrome 中可能因版本差异表现不一
- 滥用会导致图层爆炸，长列表中每个 item 都加
translateZ(0)，内存和重绘开销陡增
真正可靠的像素对齐方案
优先砍掉合成层依赖，改用不触发重排重绘的原生布局机制。
- 居中场景直接换
display: flex：父容器设display: flex; justify-content: center; align-items: center;，子元素去掉position: absolute和transform - 静态偏移改用
margin或top/left+position: relative：它们走主文档流，不进合成层，自然避开亚像素插值 - 必须用
transform时，确保值为整数：用calc()四舍五入，例如transform: translate(calc(50vw - 50%), 0)→ 改为transform: translate(calc(50vw - 50% + 0.5px), calc(-50% + 0.5px))
scale 缩放导致图像模糊的底层原因
transform: scale(0.8) 或 zoom 缩小图片/文字，是模糊主因之一——浏览器会对已渲染的内容做二次重采样，且无法保证缩放后落点为整数像素。
尤其在高 DPR 设备上，scale 运算会把本就不整的坐标进一步放大误差，比如 scale(0.5) 作用于 left: 100.3px 的元素，结果就是 50.15px，必然插值。
- 避免对
img或文字直接使用scale实现响应式缩放 - 用
srcset+sizes替代：让浏览器加载逻辑尺寸匹配的原生高清图 - 对图标类小图，可加
image-rendering: crisp-edges强制保持边缘锐度
真正难的不是加一行 translateZ(0)，而是判断这个元素是否真的需要脱离文档流、是否值得为它多建一个合成层、以及它的最终渲染坐标有没有被你亲手推到亚像素坑里。
