uni-app app端无法直接调用ios/android系统翻译接口，必须通过封装原生插件或使用三方api实现；uni.getsysteminfo().language仅返回语言标识，不提供翻译能力。
uni-app 在 App 端无法直接调用 iOS 或 Android 系统内置的翻译服务接口（比如 iOS 的 NaturalLanguage 框架或 Android 的 Translator API），因为这些原生能力未被 uni-app 官方 SDK 封装，也不在 uni. 命名空间下暴露。
你实际能走的路只有两条：封装原生插件，或绕过系统、用三方 API。
为什么 uni.getSystemInfo().language 不等于「系统翻译能力」
uni.getSystemInfo().language 只返回设备当前系统语言标识（如 zh-CN、en-US），它只是个字符串，不带任何翻译逻辑或 API 权限。很多人误以为拿到这个值就能“调系统翻译”，其实这只是语言偏好，不是翻译引擎。
App 端真要调原生翻译，必须写原生插件
如果你坚持要用 iOS 的 NSLinguisticTagger 或 Android 的 Translator（注意：Android 的 Translator 从 API 30 起需用户手动启用 Google Play Services 翻译服务，且不保证所有设备可用），就得自己写原生插件：
- iOS 需在
ios/xxx/Classes下用 Objective-C/Swift 实现翻译逻辑，并注册成uniModule； - Android 需在
android/src/main/java下用 Java/Kotlin 调用com.google.mlkit.translation.Translator或系统TextClassifier（但后者不支持翻译）； - 插件里必须处理异步回调、错误码映射（比如网络不可用、模型未下载）、目标语言校验（
envsen-US）； - 最终通过
uni.requireNativePlugin('xxxTranslation')在 JS 层调用，不能用uni.xxx直接访问。
更现实的做法：用三方翻译 API + 条件编译限定 App 端
绝大多数上线项目都跳过原生插件，直接在 App 端走 HTTPS 请求调用百度、有道或腾讯翻译 API —— 这样开发快、兼容稳、可灰度控制。关键点是：
- 必须用
uni.request（不能用fetch，iOS App 端fetch对某些 HTTPS 证书不友好）； - 签名生成逻辑（如百度的
appid+q+salt+keyMD5）必须放在前端，但key绝不能硬编码 —— 应由后端代理签发 token 或用动态密钥下发； - 加
#ifdef APP-PLUS条件编译，确保 H5 / 小程序不执行这段逻辑（避免跨域或平台限制）； - 响应字段要容错：百度返回
trans_result[0].dst，有道返回translation[0]，腾讯返回target_text，别写死解析路径。
示例片段（仅 App 端生效）：
#ifdef APP-PLUS
uni.request({
url: 'https://fanyi.baidu.com/v2transapi',
method: 'POST',
data: {
from: 'auto',
to: 'en',
query: this.inputText,
// 其他必要参数（sign、appid 等）
},
success: res => {
if (res.data.trans_result) {
this.result = res.data.trans_result[0].dst;
}
}
});
#endif
容易被忽略的坑：iOS App 端 HTTPS 证书和隐私描述
即使 API 能通，iOS 打包后常因两件事失败：
- 后台服务器用了 Let's Encrypt 旧根证书（如 DST Root CA X3），iOS 14.5+ 会拒绝握手 —— 必须升级服务器 TLS 配置；
- Info.plist 缺少
NSAppTransportSecurity配置或NSLocationWhenInUseUsageDescription等无关但被误触发的权限描述（某些翻译 API 域名被归类为“定位相关”）； - 真机调试时看不到 console.log？那是
uni.hideToast()或uni.showToast()抢占了 UI 线程，建议先用console.log+uni.showModal确认请求是否发出。
原生翻译接口不是“开箱即用”的功能，它本质是定制工程。除非你有长期维护原生插件的团队，否则老实用成熟三方 API 更省心。
