亚像素渲染偏差是浏览器将小数像素映射到物理屏幕时的必然取舍，非bug；vw/rem等单位会生成非整数像素，需通过clamp()、媒体查询、devicePixelRatio校正及避免transform/zoom等方式主动控制渲染精度。
亚像素渲染偏差不是“bug”，是浏览器把小数像素映射到物理屏幕时的必然取舍；直接硬塞 1.3px 或 42.7vw，大概率被四舍五入或插值模糊——关键不在数值本身，而在你是否控制了计算路径和渲染上下文。
为什么 vw 和 rem 会算出非整数像素
浏览器对 vw 的计算是实时浮点运算：100vw = viewport width in CSS pixels，再乘以系数（比如 4.2vw）得到一个带多位小数的 px 值；rem 同理，根字号若设为 16.3px，那 1.2rem 就是 19.56px。这些值在“计算值”阶段成立，但到“实际值”阶段，浏览器必须把它塞进离散的像素网格里。
常见现象：
-
font-size: 4.372vw在 375px 宽屏上算出16.47px→ 渲染为16px或插值模糊 -
width: calc(50% - 1px)算出187.3px→ 实际占位可能是187px，导致两列总宽374px，留出 1px 缝隙 - 高 DPI 屏（如 MacBook Retina）下
window.devicePixelRatio === 2，但 CSS 像素仍按 1:1 计算，物理像素错位更明显
用 clamp() 卡住常见设备像素比
比起无约束的 vw，clamp() 能嵌入整数基准，让浏览器在区间内优先选择对齐像素的值。它不阻止小数计算，但大幅降低落入“危险区间”的概率。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 标题类用
font-size: clamp(1.25rem, 4vw, 3rem)，其中1.25rem和3rem是整数像素锚点（假设根字号为 16px） - 避免写
clamp(1.1rem, 3.8vw, 2.9rem)——两端非整数，失去卡点意义 - 配合媒体查询做阶梯 fallback：
@media (min-width: 768px) { font-size: 18px; }，比纯流式更可控 - 慎用
vmin：它防爆炸但不防模糊，10vmin在窄屏可能落到12.3px，照样糊
手动对齐像素：用 devicePixelRatio 校正
当你必须精确控制偏移或尺寸（比如拖拽、动画起始点），不能依赖 CSS 自动计算，得自己把小数“掰回整数像素”。
示例场景（JS 控制）：
- 读取
getBoundingClientRect().left后，做Math.round(rect.left * window.devicePixelRatio) / window.devicePixelRatio再设回style.left - 动态生成
font-size时，先算出理论值，再用Math.round(value * window.devicePixelRatio) / window.devicePixelRatio截断小数位 - 不要直接用
parseInt()或Math.floor()——会系统性向下偏移，Math.round()更中性 - 注意：该操作需在
requestAnimationFrame中执行，避开 layout thrashing
哪些地方最容易漏掉亚像素校验
真正出问题的往往不是你写的 1.5px，而是你没意识到它已被层层放大：
-
transform: scale(0.8)容器内的文字，哪怕字号是整数，缩放后也变成亚像素 → 改用font-size调整，别用transform - 父级用了
zoom: 1.25（尤其 IE 遗留代码），子元素所有px值都被乘 → 检查 computed styles 里的zoom是否生效 - 第三方 UI 库组件内部用了
calc(100% / 3)布局三列，33.333...% 在不同容器宽下反复触发舍入误差 → 换成flex: 1或grid-template-columns: repeat(3, 1fr) - DevTools 里看到的 “computed” 值是
19.83px，但你没检查它是否已进入“实际值”阶段 —— 切换到 Rendering 面板开“Paint Flashing”，看哪块真被重绘了
