uni.getSystemInfoSync()是最稳的获取方式，同步返回完整设备信息，避免异步时机问题；model字段才是手机型号，brand为厂商名，platform仅为运行平台；真机调试才可靠，精确识别需UTS调原生API。
uni.getSystemInfoSync() 是最稳的获取方式
绝大多数场景下，直接用 uni.getSystemInfoSync() 就够了——它同步返回完整设备信息，不涉及回调、Promise 或平台差异处理，也不会因异步时机问题拿不到值。
常见错误现象：有人在 onLoad 里写 uni.getSystemInfo()（异步版）却没等 success 回调就直接用 res，结果拿到 undefined；还有人误以为要先调 uni.getDeviceInfo() 才能取型号，其实它只返回 platform（"ios"/"android"）和一些极简字段，不包含 model。
-
model字段才是「手机型号」，比如 "iPhone 15 Pro" 或 "Xiaomi 23127PN0CC" -
brand是厂商名，如 "Apple"、"Xiaomi"，但部分安卓定制系统可能返回空或 "unknown" -
platform是运行平台（"ios"/"android"/"harmony"），不是手机型号，别混淆 - 真机调试时才可靠，HBuilderX 模拟器返回的是模拟值，不能用于判断硬件能力
需要精确到芯片/代际？得用 UTS 直接调原生 API
当项目要求识别是否为 M系列 Mac（macOS）、是否搭载 A17 芯片、或想读取 Build.MODEL 原始字符串（比如区分 "SM-S918B" 和 "SM-S918U"）时，uni.getSystemInfoSync() 的 model 会被规范化（如统一成 "Samsung Galaxy S23"），这时必须进 UTS 层。
使用场景：做灰度发布开关、适配某款新机型独有 bug、对接硬件 SDK 要求精确设备指纹。
- Android 端在 UTS 中写
import Build from 'android.os.Build'，然后用Build.MODEL或Build.DEVICE - iOS 端用
UTSiOS.UIDevice.currentDevice.model（返回 "iPhone" 或 "iPad"）配合UTSiOS.NSProcessInfo.processInfo.environment["SIMULATOR_DEVICE_NAME"]辅助判断 - 鸿蒙端需检查
osHarmonySDKAPIVersion是否 ≥ 14，再调@ohos.deviceInfo模块 - 注意：UTS 代码无法在 H5 平台运行，务必加平台判断或 fallback
model 字段在不同平台表现不一致
model 看似统一，实则各端填充逻辑不同，容易引发兼容性问题。比如 iOS 返回 "iPhone15,2" 这类代号，而 Android 多数返回用户可见型号（但 OEM 定制 ROM 可能乱填）。
性能影响小，但逻辑判断时若写死字符串匹配（如 res.model.includes("iPhone 15")），上线后可能漏掉部分设备。
- 不要依赖
model做精确机型白名单，优先用platform+system+SDKVersion组合判断 - 华为/荣耀设备可能返回 "HMA-AL00" 这类内部型号，
brand却是 "HUAWEI"，需额外兼容 - 鸿蒙 NEXT（纯血鸿蒙）下
uni.getSystemInfoSync().model返回值尚未完全对齐安卓/iOS，建议用uni.getDeviceInfo().osHarmonySDKAPIVersion辅助识别
别在 onLaunch 里盲目缓存 deviceInfo
有人习惯在 App.vue 的 onLaunch 里调一次 uni.getSystemInfoSync() 存到 vuex 或 globalData，觉得“只查一次更省”。但实际中，这个值可能被后续热更新、分包加载、甚至某些插件重置。
使用场景：启动页展示设备型号、埋点初始化、动态加载资源前做兼容判断。
- 如果只是页面内用，就在页面
onLoad里调，别跨生命周期强依赖 - 若真要全局缓存，请用
uni.setStorageSync存一次，并加时间戳校验，避免旧值残留超过 24 小时 - 特别注意：鸿蒙平台首次安装后，
onLaunch可能触发两次（冷启+热启），重复写缓存会导致覆盖异常
真正麻烦的不是怎么取，而是取回来之后发现 model 不可比、brand 不可信、platform 在鸿蒙 NEXT 里突然多了一个 "harmony" 值——这些边界情况，文档很少写，但线上一出问题就是整批用户不可用。
