文字旋转模糊的根本原因是非90°整数倍旋转导致亚像素坐标，合成层强制对齐整数像素使子像素抗锯齿失效；filter: blur(0)仅偶发绕过渲染缓存，不稳定；真正解法是控制变换结果为整数像素，如calc()补偿、整数缩放比、避免奇数尺寸与百分比组合。
transform: rotate() 后文字模糊的根本原因
不是所有旋转都会模糊，但 rotate(5deg)、rotate(12.3deg) 这类非 90° 整数倍的值几乎必然触发。浏览器在计算旋转后的坐标时，会生成带小数的像素位置（比如 left: 102.73px），而合成层（Composite Layer）强制对齐到整数像素网格，导致亚像素渲染失效——文字边缘不再能利用 RGB 子像素做精细抗锯齿，退化为灰度模糊。
关键点：模糊发生在「合成层内文字重绘」阶段，和字体本身无关，也和 font-smoothing 设置关系不大；Chrome/Edge 尤其明显，Firefox 和 Safari 因渲染策略不同，表现稍好。
filter: blur(0) 为什么有时“有效”
它本质是欺骗浏览器：添加一个无实际效果的滤镜，会强制元素重建渲染上下文，有时恰好绕过旧合成层的缓存错误或插值残留。但这属于副作用，并不稳定：
-
filter: blur(0)会额外创建一层合成层，可能加剧内存占用或触发不必要的重绘 - 在某些 Chrome 版本（如 120+）中已基本失效，DevTools 的 Layers 面板能看到它并未改变图层结构
- 若同时存在
will-change: transform，blur(0)往往完全没反应
transform: rotateZ(0) 是无效补救
rotateZ(0) 和 rotate(0) 完全等价，不会改变任何渲染行为。它既不重建图层，也不修正坐标取整逻辑，更不会启用子像素渲染。实测中加了这行和没加，在 Layers 面板和 Rendering 标签页里没有任何差异。
真正起作用的是类似 transform: translateZ(0) 或 will-change: transform 这类强制提升合成层的操作——但它们本身反而是模糊的诱因之一，不能用来“修复”模糊。
真正可靠的做法：避开小数坐标 + 控制缩放基数
模糊的核心是「变换后位置/尺寸含小数」，所以解法必须从源头控制计算结果：
- 用
calc()确保位移为整数：transform: translateY(calc(-50% + 0.5px))→ 当父容器高为奇数时，手动补偿半像素 - 缩放优先用整数比：
scale(1.25)比scale(1.2)更安全（16px × 1.25 = 20px，刚好整像素） - 避免百分比 + 奇数尺寸组合：如
height: 475px; transform: translateY(-50%)→ 产生 237.5px，直接改height: 476px或加margin-top: -238px - 对动画中的动态值，用
Math.round()在 JS 中预处理后再设为style.transform
最常被忽略的一点：模糊是否出现，高度依赖设备像素比（dpr）。dpr = 1 的普通屏上极易复现，而 dpr ≥ 2 的 Retina 屏因物理像素密度高，小数偏移被自然“稀释”，问题反而不明显——这意味着本地开发时没看到模糊，不代表线上用户看不到。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
