模糊不是 bug，是浏览器对非整数像素变换的渲染妥协；修复核心是确保 transform 计算结果为整数像素值，而非依赖视觉“差不多”，因小数位移/缩放触发GPU双线性插值导致文字发虚。
直接结论：模糊不是 bug，是浏览器对非整数像素变换的渲染妥协；修复核心是确保 transform 计算结果为整数像素值，而非依赖视觉“差不多”
为什么 translate() 和 scale() 会让文字变虚
根本原因是浏览器把应用了 transform 的元素提升到独立合成层（GPU 层），此时文本不再走原生子像素渲染路径，而是被当作位图纹理处理。一旦位移、缩放或旋转值含小数（比如 translate(50%, 0) 在宽度为 199px 的容器里算出 99.5px），GPU 就必须做双线性插值，边缘自然发虚。
- 典型诱因：
translate(50%, -50%)居中、scale(1.3)、rotate(7deg)、JS 动态计算未取整 - 验证方法：DevTools 里临时删掉元素所有
transform声明，文字立刻变锐利 → 基本锁定问题来源 - 注意：模糊只出现在变换元素上，同级普通定位文字清晰，说明不是字体或抗锯齿全局设置问题
JS 动态设置时如何保证整数像素
不能靠浏览器自动舍入，必须在 JS 中显式取整。否则哪怕你写 translate(100px, 0)，若实际计算来自 offsetWidth / 2（如 100.5），最终生效值仍是小数。
- 用
Math.round()包裹计算值：element.style.transform = `translate(${Math.round(x)}px, ${Math.round(y)}px)` - 避免直接用百分比驱动：
translate(50%, 0)在奇数宽容器中必然产生小数，改用calc()拆解，例如：transform: translate(calc(50% - 200px), 0) - 动画关键帧里显式写整数：
@keyframes slide { from { transform: translateX(0); } to { transform: translateX(100px); } }，别用translateX(100%)
什么时候该放弃 transform 改用传统定位
硬件加速有代价，静态场景优先选更稳的方案。强行加 transform 不仅模糊，还可能触发不必要的合成层，拖慢渲染。
立即学习“前端免费学习笔记（深入）”；
- 居中应靠
display: flex+align-items/justify-content，而非额外加transform: translate(-50%, -50%) - 缩放需求不强时，优先考虑
font-size调整或容器尺寸控制，而非scale() - 慎用
will-change: transform和translateZ(0)—— 它们会强化合成层行为，反而放大模糊；尤其当配合小数变换时，等于“提醒浏览器：请用最糙的方式渲染这个文字”
最常被忽略的一点：模糊往往只在特定设备像素比（window.devicePixelRatio > 1）下明显，开发时若只在标准屏测试，上线后高 DPI 设备用户就会看到发虚文字。
