android 10+/ios 系统级禁用 imei，可靠设备标识需链式 fallback：oaid → android_id → 本地 v4 uuid；oaid 需厂商 sdk 支持且仅 app 平台生效，首次启动必须 onlaunch 预热并三重落盘持久化。
Android 10+ 和 iOS 全系已系统级禁用 IMEI 获取，plus.device.imei 返回空、固定伪码或直接抛 SecurityException，这不是代码问题，是平台强制拦截。真正能落地的方案是链式 fallback：OAID → android_id → 本地生成 v4 UUID，且必须首次启动即持久化。
uni.getOAID 为什么调用后返回空或 00000000-0000-0000-0000-000000000000
这是最常被误判为“代码没写对”的场景。根本原因有三个：uni.getOAID 不是开箱即用 API，它依赖厂商 SDK（如 MSA、HMS）且只在「App 平台」生效；H5/小程序环境直接 undefined；真机上返回空，大概率是基座未启用 OAID 支持或厂商服务未就绪。
- 确认你打包的是 App（不是 H5），并在
manifest.json的「App 模块配置」中勾选「OAID 支持」 - 调试时必须用自定义基座（HBuilderX → 运行 → 选择「自定义基座」），云编译默认基座不带 OAID 能力
- 华为设备需预装 HMS Core，小米/OPPO/vivo 需系统版本 ≥ MIUI 12.5 / ColorOS 11.2 / Funtouch OS 12，否则
oaid为空 - 首次调用有 200–500ms 初始化延迟，不能等到登录页才触发——必须在
App.vue的onLaunch中预热并缓存 - 务必加判断：
if (!res.oaid || res.oaid === '00000000-0000-0000-0000-000000000000')，视为失败立即降级
为什么不能直接用 plus.device.androidId，而要桥接 Settings.Secure.getString
plus.device.androidId 在新版 5+ Runtime 中已被弃用，实测返回 undefined 或空字符串；真正可用的是原生 Settings.Secure.getString(cr, "android_id")，它兼容 Android 5.0+、无需权限、不随应用卸载重置——但厂商魔改严重，必须桥接并兜底。
- 必须用
plus.android.importClass('android.provider.Settings$Secure')导入类，再调用getString - 获取
ContentResolver需通过main.getContentResolver()，不能硬写 context - 某些 EU 版 MIUI、vivo Funtouch OS、华为鸿蒙 3.0+ 会返回
null或固定值（如9774d56d682e549c），必须加空值判断 - 建议拼接
Build.SERIAL（非"unknown"时）增强区分度：plus.android.importClass('android.os.Build').SERIAL - 该值在恢复出厂或刷机后会变，但比 UUID 稳定得多——它不依赖应用层存储，是系统级标识
本地 UUID 必须三重落盘，且不能用 Math.random() 拼接
当 OAID 和 android_id 全部失效（如用户拒权、低端 ROM、无厂商服务），唯一兜底是自己生成标准 v4 UUID 并确保不丢失。常见错误是只存 uni.setStorageSync，结果清缓存就重置；更错的是用 Date.now() + Math.random() 伪造，碰撞概率高且不满足稳定要求。
- 首次启动必须检测：
uni.getStorageSync('device_id')，不存在才生成 - 生成必须用标准 v4 格式：
'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, c => { const r = Math.random() * 16 | 0; return (c === 'x' ? r : (r & 0x3 | 0x8)).toString(16); }) - 必须三重落盘：同步写入
uni.setStorageSync('device_id', id)、plus.storage.setItem('device_id', id)、以及文件系统（如uni.getFileSystemManager().writeFile）防清缓存 - iOS 上
plus.device.uuid行为不可控，Android 上它由基座动态生成、卸载重装必变，所以它只能作临时会话 ID，绝不能当设备标识 - 该 UUID 的生命周期止于用户清除 App 全部数据；如需长期绑定，请在登录后将该 ID 与用户账号在服务端做映射
最容易被忽略的点是：没有「首次启动检测」逻辑。所有标识都必须在 onLaunch 中完成链式尝试 + 持久化，后续启动直接读缓存。任何把生成逻辑放在页面 onLoad 或 API 回调里的做法，都会导致多端 ID 不一致、重复生成、甚至竞态写入。
