半像素模糊源于浏览器按实际尺寸计算-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 屏上，文字边缘发虚、边框毛边。
- 别信“设成偶数宽高就安全”——
width: 400px在zoom: 110%下计算出的-50%仍是小数 -
calc(-50% + 0.5px)不是万能解，它只是偏移补偿，若基础值本身含浮点误差（如100vw），结果仍可能非整 - 用
getBoundingClientRect().left在控制台打印真实坐标，一眼看出是否带小数
为什么 translateZ(0) 有时清晰、有时更糊
translateZ(0) 不修复模糊，只改变渲染路径：它强制创建独立合成层，把元素交给 GPU 单独光栅化。GPU 若恰好把图层对齐到整数物理像素，看起来锐利；若原始位移仍是 translate(-384.5px, 20.7px)，GPU 照样插值——模糊照旧，甚至因多一层图层叠加，抗锯齿更明显。
实操建议：
- Safari 对亚像素更敏感，
translateZ(0)在 iOS 上失效概率远高于 Chrome - 滥用会触发“图层爆炸”，长列表中每个 item 都加，内存占用飙升，滚动卡顿
- 先看 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 替代方案（兼容性优先）：
- 放弃
translate(-50%, -50%)，改用display: flex; justify-content: center; align-items: center;—— 不触发合成层，走主文档流渲染，保留 sub-pixel 渲染能力 - 必须用绝对定位时，用
top: 50%; left: 50%; margin-left: -Apx; margin-top: -Bpx;（A/B 为固定像素值），前提是子元素尺寸确定且不响应式变化 - 静态图标居中，直接用
inline-block+line-height或font-size控制，比 transform 更像素友好
移动端 Safari 特别容易翻车的点
iOS Safari 对字体亚像素渲染极其敏感，transform + font-smoothing 组合常失效。真机验证比模拟器可靠得多。
关键动作：
- 禁用
-webkit-font-smoothing: antialiased（它强制关闭 sub-pixel，反而让文字更糊） - 仅对主文档层生效：加
-webkit-font-smoothing: subpixel-antialiased到根元素或弹窗 wrapper 上 - 搭配
text-rendering: optimizeLegibility，辅助浏览器选更优字形 hinting - 如果仍糊，立刻砍掉
transform，换回position: relative+margin或flex
最常被忽略的是：模糊是否真实存在，得看 Layers 面板；而是否在真机上糊，得拿 iPhone 实测——模拟器的 DPR 模拟经常不准。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
