transform本身不会解决像素模糊，反而是模糊源头；真正有效的是让其位移值对齐整数物理像素，如用Math.round(value×DPR)/DPR校准JS计算值、CSS中以calc()替代百分比、避免position:fixed与transform混用。
transform 本身不会解决像素模糊，反而常是模糊源头
直接用 transform 做定位（比如居中、偏移）时，只要计算结果含小数像素，就大概率触发亚像素渲染——浏览器把文字画在物理像素中间，靠插值补色，结果就是发虚。这不是 bug，是 GPU 合成层的正常行为。想“用 transform 解决模糊”，方向就错了；真正要做的，是让 transform 的值落到整数物理像素上。
用 calc() 替代百分比位移，强制 CSS 层面像素对齐
常见错误写法：transform: translate(-50%, -50%)。它依赖运行时尺寸，父容器宽高为奇数时，-50% 就是 xxx.5px，必糊。
-
transform: translate(calc(-50% + 0.5px), calc(-50% + 0.5px))这类“加 0.5px 补偿”只在 DPR=1 且视口无缩放时偶然有效，不可靠 - 更稳妥的是锚定已知整数尺寸：比如元素固定宽 400px，用
transform: translate(calc(-50% + 200px), 0)，把百分比和像素混算提前收束为整数 - 若需响应式，优先用
calc(50vw - 200px)而非translateX(50%)，因为vw单位在 CSS 计算阶段更易对齐视口像素
JS 动态设置 transform 时，必须 round 到设备像素
用 getBoundingClientRect() 或 offsetWidth 算出的值默认是逻辑像素，直接塞进 transform 会失准。尤其在 Retina 屏（window.devicePixelRatio === 2）或页面 zoom ≠ 1 时，1.3px 逻辑值可能对应 2.6 物理像素。
- 正确做法：
el.style.transform = `translateY(${Math.round(y * window.devicePixelRatio) / window.devicePixelRatio}px)` - 别只用
Math.round(y)——那只是四舍五入到逻辑像素，没考虑设备实际采样密度 - 滚动或缩放时，
window.visualViewport?.offsetLeft和window.devicePixelRatio可能变化，需监听重算
position: fixed + transform 混用时，校准难度翻倍
position: fixed 元素本就按视口坐标系定位，叠加 transform 后，浏览器要同时处理视口滚动、DPR 变化、缩放三重影响。例如 transform: translateX(-50%) 的 “50%” 是按初始视口算？缩放后视口算？还是 visualViewport 宽度算？答案不唯一，容易错位+模糊。
立即学习“前端免费学习笔记（深入）”；
- 避免直接在
fixed元素上写translate(-50%, -50%)居中 - 改用
left: 50%; top: 50%; margin-left: -200px; margin-top: -30px;，绕过 transform 合成层 - 若必须用 transform，先检查
el.getBoundingClientRect().left是否为整数，不是就手动 round 后再设transform
最常被忽略的一点：模糊是否真实由 transform 引起，得看 Chrome DevTools 的 Layers 面板。没看到 “Composited” 标记，说明根本没进 GPU 渲染流程，此时加 will-change 或 translateZ(0) 不仅无效，反而引入额外开销。
