CSS transform 导致字体发虚，根本原因并不是 transform 写法错误，而是文字被移动到了非整数像素位置，进而触发 GPU 双线性插值。解决这类字体模糊问题的关键，在于确保 translate、scale、rotate 的最终结果严格落在整数物理像素上，而不是依赖 translateZ(0) 或 will-change 这类硬件加速手段。
先说结论：CSS 字体发虚并不是因为 transform 属性本身写错，而是它把文字推到了非整数像素位置，从而触发 GPU 双线性插值渲染。真正有效的解决方法，是让 translate、scale、rotate 的最终计算值准确落在整数物理像素上，而不是依靠 translateZ(0) 或 will-change 强行开启硬件加速。
为什么 translate(50%, -50%) 居中会发虚
使用百分比位移时，位移值依赖容器尺寸，而容器宽高经常是奇数，例如 301px，此时 50% 计算后就是 150.5px。这个 .5 会让浏览器在渲染文字时进行亚像素插值，文字边缘很容易变软、发糊。Chrome 和 Edge 对这种情况尤其敏感，哪怕只偏差 0.1px，也可能出现文字模糊。
实操建议：
- 静态居中场景优先使用
display: flex+justify-content/align-items，或者position: absolute+top: 50%+transform: translateY(-50%)，同时尽量保证父容器宽高为偶数 - 必须使用百分比位移时，可先读取
el.offsetWidth，再通过Math.round(value * window.devicePixelRatio) / window.devicePixelRatio做像素校准 - 在 DevTools 中临时移除
transform，如果文字立刻恢复清晰，通常就能快速定位到字体发虚的来源
JS 动态设置 transform 时怎么避免小数
浏览器不会自动把 getBoundingClientRect() 的结果或动画插值过程中的数值取整。如果 JS 层不主动处理，小数位移带来的字体模糊几乎不可避免。
实操建议：
- 所有位移坐标统一包一层
Math.round()：element.style.transform = `translate(${Math.round(x)}px, ${Math.round(y)}px)` - 动画执行过程中每一帧都要检查：即使起点和终点都是整数，中间帧也可能产生
123.742px这样的浮点值，建议用requestAnimationFrame+ 取整做兜底处理 - 谨慎使用
transform: scale(1.2)这类浮点缩放；像scale(1)、scale(2)更安全，而scale(1.5)已经属于较高风险写法
rotate 和 scale 怎么控制不糊
rotate(5deg) 或 scale(1.1) 虽然表面上看不出明显位移，但它们同样会让文字纹理在 GPU 合成层中被重新采样。一旦像素映射不精确，文字就会出现发虚、发糊的问题。
实操建议：
- 旋转尽量优先使用
90deg、180deg这类整数倍角度，避免小角度旋转；像rotate(7deg)这类写法通常很容易导致文字模糊 - 缩放比例尽量选择整数或可整除字号的比例：例如
font-size: 16px配合scale(1.25)得到20px，通常会比scale(1.23)更稳定 - 尽量避免复合写法：
transform: scale(1.1) rotate(2deg)会叠加采样误差，相比单独使用某一种变换更容易造成字体发虚
什么时候该放弃 transform 改用传统定位
硬件加速并不是没有代价。对于静态居中、固定缩放、没有交互需求的位移场景，完全没必要优先使用 transform——它反而可能引入新的合成层以及插值模糊风险。
实操建议：
- 纯居中场景优先考虑
flex或grid；如果需要兼容老旧浏览器，可以使用position: absolute+margin: auto - 缩放需求不强时，直接调整
font-size或容器的width/height，通常会比使用scale()更清晰、更稳定 - 不要随意添加
will-change: transform：建议在动画开始前一刻再设置，最后一帧通过requestAnimationFrame清除；否则不仅会让图层长期驻留、增加内存占用，在 Safari 中还可能让文字更模糊
最容易被忽视的问题在于：这类字体模糊通常不会报错，也没有明显警告，只会在特定 DPI、页面缩放比例或浏览器版本下偶发出现。一旦长期依赖 translateZ(0) 这种“看起来有效”的临时方案，后续在 iOS 设备或高分屏环境下大概率会暴露更明显的兼容性问题。
