纯前端无法100%可靠检测模拟器，但可通过plus.device.cpuType、Build.FINGERPRINT、TelephonyManager等原生特征组合判断；Android模拟器高危信号包括x86架构、"generic/sdk/emulator"指纹、getSimState()异常；需用原生插件读取/proc/cpuinfo和ro.kernel.qemu增强可靠性，避免仅依赖userAgent。
uni-app App端怎么检测是否在模拟器里运行
直接结论：纯前端无法100%可靠检测模拟器，但可以通过组合多个低层特征做高置信度判断——重点不是“能不能”，而是“哪些特征在真机/模拟器间差异最大、且不易被绕过”。
Android 模拟器普遍暴露的硬件指纹和系统行为与真机不同，iOS 模拟器则根本不能打包上架（Xcode 只允许真机调试），所以实际只需防 Android 模拟器。核心思路是避开 Webview 层面的伪检测（比如只看 navigator.userAgent），深入到 plus.runtime 和原生扩展能力。
-
plus.device.model和plus.device.vendor返回空、"Android SDK built for x86"、"google_sdk"、"sdk_google_phone_x86" 等字符串是强信号 -
plus.os.name === 'Android'且plus.device.cpuType为"x86"或"x86_64"（真机几乎全是"arm64-v8a"或"armeabi-v7a"） - 调用
plus.android.importClass('android.os.Build')获取Build.FINGERPRINT，含"generic/"、"sdk/"、"emulator"等关键词 - 检查
plus.android.importClass('android.telephony.TelephonyManager')是否能获取getDeviceId()或getSimState()—— 多数模拟器返回null或抛异常
为什么 navigator.platform 和 userAgent 完全不可信
因为它们只是 Webview 的 JS 运行环境标识，而模拟器厂商（如夜神、MuMu、雷电）默认把 UA 设成跟主流机型一致，甚至允许用户自定义。更关键的是：uni-app 的 web-view 或 H5 模式下这些字段才生效，App 端真正跑的是原生容器 + WebView，userAgent 完全可被壳层篡改。
实操建议：别在 onLoad 里只写 if (navigator.userAgent.includes('Emulator')) —— 这种代码上线后等于没写。
- 真机上也可能出现类似字符串（比如某些定制 ROM 的 UA 里带 "Build"）
- 模拟器启动时若关闭网络或未初始化 Telephony 服务，
getSimState()报错反而比返回假值更可信 - 单纯依赖
plus.device.model也不够，有些模拟器会伪造成 "MI 9" 或 "iPhone12,1"，必须配合 CPU 架构+Build 信息交叉验证
如何用原生插件补足 JS 层检测盲区
JS 层能拿到的信息有限且易伪造，真正可靠的检测必须下沉到原生。uni-app 支持自定义原生插件（Android 用 .aar，iOS 用 .framework），这是防模拟器的分水岭。
推荐在插件里做三件事：
- 读取
/proc/cpuinfo判断是否含"QEMU"或"goldfish"（模拟器内核特征） - 检查
getprop ro.kernel.qemu是否为"1"（Android 模拟器特有属性） - 调用
ActivityManager.getRunningAppProcesses()看进程名是否含"qemu-props"、"emulator"
注意：这类操作需要 android.permission.READ_PHONE_STATE（Android 10+ 已废弃该权限用于设备识别），所以更稳妥的做法是申请 android.permission.QUERY_ALL_PACKAGES（需动态申请）并结合进程扫描。插件返回布尔值给 JS 层，比纯 JS 判断可靠一个数量级。
上线前最容易忽略的兼容性陷阱
很多团队测完夜神、雷电就以为过关，结果上线后被 MuMu 12 或新出的 WSA（Windows Subsystem for Android）绕过。根本原因是：不同模拟器内核版本、系统镜像、虚拟化技术（QEMU vs Hyper-V）差异极大，没有银弹方案。
必须做两件事：
- 白名单式兜底：对已知安全的
plus.device.model+plus.device.cpuType组合（如"Xiaomi MI 8"+"arm64-v8a"）直接放行，不参与后续检测 - 拒绝策略要分级：发现可疑特征时，先
console.warn上报日志，灰度阶段不直接退出，等数据积累一周再切为plus.navigator.closeWebview()或跳转提示页 - 避免在
App.vue的onLaunch里同步阻塞执行所有检测——部分插件初始化耗时 >300ms，会导致冷启动卡顿，应异步 + 超时控制
真实情况是：越想“彻底封死”模拟器，越容易误杀低端真机（比如某些展讯芯片手机也返回 x86 CPU Type）。留一点模糊空间，比追求 100% 准确更实用。
