小数像素边框错位是高 dpr 下物理像素映射的必然结果，非 bug；无通用修复，需按场景规避，核心是控制渲染落点。
小数像素边框错位不是 bug，是浏览器在高 DPR 设备上做物理像素映射时的必然结果；没有“通用修复”，只有按场景规避——关键在控制渲染落点，而非强行四舍五入。
为什么 border: 0.5px 在 Safari 和 Chrome 表现不同
Chrome 对 subpixel 渲染更宽容，会保留 0.5px 的抗锯齿边缘；Safari（尤其是 iOS）倾向将 0.5px 四舍五入为 0px 或 1px，导致相邻元素一个有线、一个无线。Firefox 则可能生成半透明像素，视觉发虚。这不是计算错误，而是光栅化阶段对 window.devicePixelRatio 的处理策略差异。
- 用
getBoundingClientRect().width查到的是逻辑像素值（如42.3），但真实绘制已按 DPR 换算并取整 -
border: 0.5px在 DPR=2 下本应占 1 物理像素，但 Safari 可能直接跳过渲染（因低于最小可显单位） - 伪元素模拟边框（
::after { height: 1px; background: #ccc; transform: scaleY(0.5); }）比原生border更可控，因缩放发生在合成层，精度更高
用伪元素 + transform: scaleY() 替代小数边框
这是目前跨浏览器最稳的物理像素边框方案，核心是把“画 1 物理像素”这件事交给缩放控制，绕过浏览器对小数 border-width 的舍入逻辑。
- 父容器必须设
position: relative，否则::after的position: absolute会脱标到body - 伪元素写法：
::after { content: ""; position: absolute; left: 0; right: 0; bottom: 0; height: 1px; background: #ccc; transform: scaleY(0.5); transform-origin: 0 100%; } -
transform-origin: 0 100%必须写全，Safari 对bottom关键词解析不稳定 - 务必加
pointer-events: none，否则安卓 WebView 可能拦截点击事件 - 不要用
border-bottom，它受box-sizing和line-height干扰，而纯height + background更干净
避免 transform 与百分比混用放大 subpixel 偏差
top: 50%; transform: translateY(-50%) 这类组合是 subpixel 错位的放大器：第一次计算 50% 得到小数值（如 42.3px），第二次 translateY(-42.3px) 再次触发舍入，两次误差叠加后偏移可达 0.6px 级别，在 DPR=3 设备上肉眼可见。
- 改用
inset（现代支持）：inset: 50% auto auto 50%; transform: translate(50%, 50%);，减少一次百分比计算 - 或手动四舍五入到物理像素：
const y = Math.round(el.offsetHeight * 0.5 * window.devicePixelRatio) / window.devicePixelRatio; - 禁用
will-change: transform，Safari 可能跳过 subpixel 优化，直接走图层合成，反而让偏差更明显 - 滚动吸顶、模态框居中等关键动效，优先用
position: sticky或place-items: center，避开手写transform
真机测试时最容易被忽略的三个点
DevTools 的 device toolbar 能稳定复现问题，但上线后用户反馈的错位往往来自你没测到的场景：
-
text-size-adjust: none没加：iOS「更大字体」系统设置会让字号非整数，连带rem计算出的边框也变小数 -
clamp()的 fallback 值没生效：比如font-size: clamp(14px, 2.5vw, 18px)，在窄屏下若2.5vw算出15.7px，仍会触发 subpixel - 全局
* { box-sizing: border-box }被某个!important覆盖：Computed 面板里该规则被划掉，但你只看了 Styles 面板
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
