CSS定位居中为什么会出现半像素模糊

半像素模糊源于浏览器按实际尺寸计算-50%产生小数，如769px宽父容器对应-384.5px，DPR=2时GPU无法精准渲染半个物理像素，导致插值模糊；常见于fixed弹窗、tooltip等场景，需JS动态校准坐标或改用flex居中等方案规避。

transform: translate(-50%, -50%) 怎么算出半像素

不是写错代码，而是浏览器按实际尺寸做数学运算时自然产生小数。比如父容器宽度是 769px，-50% 就是 -384.5px；DPR=2 的 Retina 屏上，这等于移动 769 个物理像素的一半——384.5 个 CSS 像素 → 769 个物理像素，但 GPU 渲染时无法把文字或边框精准打在半个物理像素上，只能插值模糊。

常见错误现象：position: fixed 弹窗、tooltip、轮播焦点图用该写法，在 iPhone 或缩放为 125% 的 Windows 屏上，文字边缘发虚、边框毛边。

1. 别信“设成偶数宽高就安全”——width: 400px 在 zoom: 110% 下计算出的 -50% 仍是小数
2. calc(-50% + 0.5px) 不是万能解，它只是偏移补偿，若基础值本身含浮点误差（如 100vw），结果仍可能非整
3. 用 getBoundingClientRect().left 在控制台打印真实坐标，一眼看出是否带小数

为什么 translateZ(0) 有时清晰、有时更糊

translateZ(0) 不修复模糊，只改变渲染路径：它强制创建独立合成层，把元素交给 GPU 单独光栅化。GPU 若恰好把图层对齐到整数物理像素，看起来锐利；若原始位移仍是 translate(-384.5px, 20.7px)，GPU 照样插值——模糊照旧，甚至因多一层图层叠加，抗锯齿更明显。

实操建议：

1. Safari 对亚像素更敏感，translateZ(0) 在 iOS 上失效概率远高于 Chrome
2. 滥用会触发“图层爆炸”，长列表中每个 item 都加，内存占用飙升，滚动卡顿
3. 先看 DevTools 的 Layers 面板：没标 Composited，说明根本没进 GPU 渲染，加 translateZ(0) 纯属徒劳

真正有效的像素对齐方案

核心只有一条：让最终渲染坐标落在整数物理像素上。不能靠肉眼调，得靠计算兜底。

JS 动态校准（最稳）：

const x = (window.innerWidth / 2) - (el.offsetWidth / 2);el.style.transform = `translate(${Math.round(x * window.devicePixelRatio) / window.devicePixelRatio}px, 0)`;

CSS 替代方案（兼容性优先）：

1. 放弃 translate(-50%, -50%)，改用 display: flex; justify-content: center; align-items: center; —— 不触发合成层，走主文档流渲染，保留 sub-pixel 渲染能力
2. 必须用绝对定位时，用 top: 50%; left: 50%; margin-left: -Apx; margin-top: -Bpx;（A/B 为固定像素值），前提是子元素尺寸确定且不响应式变化
3. 静态图标居中，直接用 inline-block + line-height 或 font-size 控制，比 transform 更像素友好

移动端 Safari 特别容易翻车的点

iOS Safari 对字体亚像素渲染极其敏感，transform + font-smoothing 组合常失效。真机验证比模拟器可靠得多。

关键动作：

1. 禁用 -webkit-font-smoothing: antialiased（它强制关闭 sub-pixel，反而让文字更糊）
2. 仅对主文档层生效：加 -webkit-font-smoothing: subpixel-antialiased 到根元素或弹窗 wrapper 上
3. 搭配 text-rendering: optimizeLegibility，辅助浏览器选更优字形 hinting
4. 如果仍糊，立刻砍掉 transform，换回 position: relative + margin 或 flex

最常被忽略的是：模糊是否真实存在，得看 Layers 面板；而是否在真机上糊，得拿 iPhone 实测——模拟器的 DPR 模拟经常不准。