uni.getSystemInfoSync()不返回UUID，需首次启动时生成并三重存储（文件/plus.storage/uni.setStorageSync），Android优先OAID，iOS只能自建UUID并持久化，所有前端ID须服务端校验。
uni.getSystemInfoSync() 不能直接拿到 UUID，得自己存
很多人以为调用 uni.getsysteminfosync() 就能顺手捞出设备 id，结果发现返回对象里压根没有 uuid 字段——没错，它只给设备信息，不生成也不持久化标识。真正可用的 plus.device.uuid 是 dcloud 原生层提供的，但它有硬伤：应用卸载重装后会变，而且在部分 android 12+ 设备上（尤其厂商定制系统）可能返回空或固定值。
- 必须首次启动时主动生成并写入本地存储，否则每次冷启都“失忆”
-
uni.setStorageSync('device_uuid', uuid)是最简方案，但注意 iOS 17+ 对uni.setStorageSync的沙盒限制变严，偶尔写失败 - 更稳的做法是用文件系统存：封装一个
DeviceStorage.js，先尝试写文件，失败再 fallback 到 storage - 别用时间戳 + 随机数拼接当 UUID——不同设备可能撞车，要用
Math.random().toString(36).substr(2, 9)这类带熵的生成逻辑
Android 上别硬刚 IMEI，OAID 才是合规主力
在 Android 10+，READ_PHONE_STATE 权限基本拿不到 IMEI，即使你在 manifest.json 里写了 "READ_PHONE_STATE"，用户授权后也大概率返回空或 "000000000000000"。华为、小米、OPPO 等厂商系统还会主动拦截，不是你代码写错了，是系统不让。
- 优先走
com.uuzuo.oaid这类成熟原生插件，它会自动降级：先试 OAID → 再试 ANDROID_ID → 最后 fallback 到自定义 UUID - OAID 可被用户手动重置（设置 → 广告与隐私 → 重置广告 ID），所以它适合做统计/推送，不适合做账号绑定
- 别自己用 Native.js 调
Settings.Secure.getString(..., 'android_id')—— Android 8.0 后该值对非系统 App 已变为 null 或常量，实测在 vivo 和 realme 上 100% 失效
iOS 没有 OAID，deviceToken 和 deviceId 不是同一回事
iOS 完全不提供类似 OAID 的机制，deviceToken 是 APNs 推送专用凭证，和设备唯一性无关；而 aliyunpush.getDeviceId() 返回的 deviceId 是阿里云 SDK 自己生成的、仅限该推送通道内有效的 ID，换一个推送服务（比如个推、极光）就完全不一样。
- 想在 iOS 上稳定识别设备，唯一靠谱路径就是：App 启动时生成 UUID → 存到
uni.setStorageSync→ 后续所有请求带上这个值 - 别试图用
plus.device.udid（已废弃）或identifierForVendor（iOS 原生），uni-app 未暴露该能力，强行桥接风险高且审核可能被拒 - 如果业务强依赖设备一致性（比如防刷、设备锁），必须配合服务端校验：同一个 UUID 频繁出现在不同 IP 或 UA 下，就得触发二次验证
UUID 存哪里？storage、file、plus.storage 全都要测一遍
你以为存进 uni.setStorageSync 就万事大吉？现实是：某些低端 Android 机型（如传音 Tecno）会因内存紧张自动清空 storage；iOS 16.4 后部分企业签名包也会触发沙盒清理；而 plus.storage 在 HBuilderX 3.9+ 版本中又存在跨进程读写异常。
- 推荐三重落盘：先写
uni.setStorageSync，再写plus.io.resolveLocalFileSystemURL文件，最后用plus.storage.setItem备份一份 - 读取时按顺序尝试：文件 → plus.storage → uni.getStorageSync，任一成功就立刻返回，避免卡顿
- 生成 UUID 的时机必须是
onLaunch里，且加个防重逻辑：先读，读不到再生成，生成完立刻存，不要等页面 ready 或网络就绪后再操作
