rpx在高分屏小程序中计算不准是因设备像素比（dpr）与逻辑像素未对齐所致；启用dynamicRpx并正确配置可校准，但1rpx仍可能渲染失败，需用transform或渐变替代。
rpx 在高分屏小程序里确实会算不准，不是你代码写错了，是底层渲染机制和设备像素比（dpr）没对齐导致的。
为什么 rpx 在某些安卓机或高刷屏上看起来“偏小”或“错位”
uni-app 的 rpx 默认按 750rpx = 屏幕宽度（逻辑像素）换算，但很多安卓厂商（尤其 OPPO、vivo、华为新机型）在高刷/高分屏下，系统上报的 window.screen.width 和实际 CSS 渲染的逻辑像素宽度不一致；微信小程序基础库在部分版本中对 systemInfo.pixelRatio 的取值也存在四舍五入误差，导致 uni-app 内部用它算出的 rpx 基准值偏大，最终所有 rpx 元素被“压缩”。
- 典型现象：
width: 750rpx的盒子没铺满屏幕，右侧留白几像素；border: 1rpx solid看起来时有时无，甚至完全不可见 - 只影响真机，尤其是 Android + 微信 8.0.32+ / 支付宝 10.3.12+，模拟器和 iOS 大多正常
- uni-app 3.99+ 已默认启用
dynamicRpx，但需配合正确配置才生效
如何开启并验证 dynamicRpx 是否真正起效
uni-app 从 3.99 开始支持动态 rpx 校准，它会在运行时读取真实设备 dpr 并重设 rpx 基准，但必须手动打开且不能依赖 H5 模式配置。
- 在
manifest.json的mp-weixin或mp-alipay节点下添加："dynamicRpx": true - 确保项目使用的是
@dcloudio/uni-app@^3.99.0及以上版本（执行npm list @dcloudio/uni-app确认） - 真机调试时，在
onLaunch中打印：uni.getSystemInfoSync().pixelRatio和document.documentElement.style.fontSize，若后者接近750 / pixelRatio（如 dpr=3.5 → fontSize≈214.2857px），说明已校准 - 禁用
vue.config.js中可能存在的css.loaderOptions.px2rem类插件，它们会和 dynamicRpx 冲突
border: 1rpx 渲染失败的替代方案
即使开了 dynamicRpx，1rpx 在 dpr=3.5 或非整数 dpr 设备上仍可能被浏览器向下取整为 0px —— 这是 CSS 渲染层限制，不是 uni-app 能绕过的。
- 优先改用
transform: scaleY(0.5)配合height: 1px，例如：style="height: 1px; transform: scaleY(0.5); transform-origin: 0 0;" - 或者用伪元素 +
background-image: linear-gradient模拟，更稳定但略增体积 - 避免在
view上直接写border: 1rpx，尤其不要用于关键分割线或边框容器 - 支付宝小程序需额外注意：
border-width不支持小数，1.5rpx会被截断为1rpx，此时必须用缩放或渐变
自定义 rpx 基准的兜底写法（慎用）
如果 dynamicRpx 因平台兼容性问题失效（比如旧版钉钉小程序），可手动重写 rpx 计算逻辑，但仅限紧急修复，不可长期依赖。
- 在
main.js最顶部加：uni.setStorageSync('rpxUnit', 750 / (wx.getSystemInfoSync().pixelRatio || 2)) - 然后在 App.vue 的
created钩子中执行：document.documentElement.style.fontSize = uni.getStorageSync('rpxUnit') + 'px' - 务必包裹
try/catch，部分低端机调用getSystemInfoSync会报错 - 此方式会覆盖 uni-app 自身的 rpx 机制，后续升级需人工核对是否冲突
最麻烦的其实是那些“看起来差不多”的机型 —— 同一品牌不同批次的同型号手机，dpr 上报值可能差 0.1，导致 rpx 偏差从 1px 变成 3px。真机测试别省，尤其要覆盖 OPPO Find X6、vivo X100、华为 Mate 60 Pro 这类 dpr=3.5/3.75 的主力机型。
