App端无法用navigator.language获取真实系统语言，因其返回WebView内核默认值而非设备设置；必须通过原生桥接（如uni-get-language插件）调用iOS NSLocale.preferredLanguages或Android Resources.getConfiguration().getLocales()获取标准BCP-47语言标签。
uni-app App端无法直接用 navigator.language 或 locale 获取系统语言，因为 iOS/Android 原生 WebView 不暴露该信息；必须调用原生模块才能读取真实系统语言设置。
为什么 navigator.language 在 App 端不可靠
打包成 App 后，navigator.language 返回的往往是 WebView 内核默认值（如 zh-CN 或 en-US），和用户设备实际设置无关。iOS 上 WKWebView 甚至可能返回空字符串或硬编码值；Android X5 或系统 WebView 表现也不一致。这不是 bug，是内核隔离导致的限制。
- 它只反映 WebView 初始化时的 locale 快照，不随系统语言切换实时更新
- H5 端能用，是因为运行在浏览器环境；App 端本质是原生容器 + 离线 WebView，无权访问系统级语言配置
- uni-app 官方 API 如
uni.getSystemInfo也未提供language字段（截至 2026 年 4 月）
App 端获取真实系统语言的两种可靠方式
必须走原生桥接。推荐使用插件市场中已验证的 uni-get-language 插件（搜“系统语言”可找到），或手动调用原生接口：
- iOS：需在原生层调用
NSLocale.preferredLanguages.firstObject，注意 iOS 16+ 对多语言顺序有调整，应取数组首项而非固定索引 - Android：调用
Resources.getConfiguration().getLocales().get(0)（API 24+），旧版本用configuration.locale，但已废弃 - 插件调用示例：
const lang = uni.requireNativePlugin('uni-get-language').get();，返回类似zh-Hans-CN或en-US的标准 BCP-47 标签
如何让多语言配置随系统语言自动切换
不能依赖页面 onLoad 一次性读取，必须监听系统语言变更事件——但 uni-app 本身不提供该事件，需插件支持或自行扩展原生模块：
- 部分插件（如
uni-language-detector）提供了onLanguageChange回调，需在onLaunch中注册 - 若用自研原生模块，iOS 需监听
NSCurrentLocaleDidChangeNotification，Android 需注册ConfigurationChanged广播 - 切记：语言变更后，
uni.setLocale只影响 uni-app 内置组件（如uni-dateformat），业务层 i18n（如 vue-i18n）需手动locale.value = lang并触发重渲染
容易被忽略的关键细节
系统语言字符串 ≠ 你 i18n 文件的 key。比如用户设的是 zh-Hant-TW，但你的翻译文件只叫 zh-TW.json，必须做标准化映射：
- 提取主语言码：
lang.split('-')[0]→zh，再 fallback 到zh-CN或zh-Hans - iOS 17+ 可能返回
zh-Hans-CN，而 Android 常返回zh-CN，两者语义相同但字符串不同 - 用户手动切换 App 内语言时，应优先覆盖系统语言，且保存到
uni.setStorageSync，避免下次启动又拉取系统值
最麻烦的其实是测试——真机调试时，改系统语言要杀掉 App 进程才能生效，模拟器常缓存旧值。别信 HBuilderX 的“模拟语言”开关，它只改 WebView 层，不触发原生回调。
