uni-app 在 App 端无法调用 iOS 或 Android 系统翻译 API，因系统接口属私有/受限 API，未向 WebView 和 JS 层开放，且无官方原生封装；可行方案仅为调用第三方网络翻译 API，并须通过云函数中转密钥以保障安全。
uni-app 在 App 端无法直接调用 iOS 或 Android 系统自带的翻译接口（如 iOS 的 NSLinguisticTagger、Android 的 TranslationManager 或系统级“实时字幕”API），这些接口未向 WebView 或 uni-app 的 JS 层开放，也无官方封装支持。
为什么 uni-app 不能调用系统翻译 API
uni-app 编译为 App 时，底层使用的是 WebView（iOS WKWebView / Android X5 或系统 WebView）+ 原生桥接机制。系统翻译能力（如 iOS 17+ 的实时翻译、Android 12+ 的系统翻译服务）属于私有或受限 API，仅允许系统应用或通过特定权限（如 android.permission.TRANSLATE）调用，且不提供 JS 可访问的 Web API 接口。
- Apple 明确禁止第三方 App 通过 JavaScript 调用
NSLinguisticTagger或系统翻译引擎做文本翻译 - Android 的
TranslationManager需要TRANSLATE权限（签名级权限），普通应用无法声明或获取 - uni-app 的
plus.android和plus.ios原生扩展也不包含对系统翻译模块的封装
替代方案：必须走网络翻译 API
实际可行路径只有调用第三方翻译服务，但要注意安全与合规：
-
百度翻译 API：需在百度翻译开放平台申请appid和key，构造带sign的 GET 请求，注意 salt 和 MD5 签名逻辑必须在客户端完成（或更推荐用云函数代理） -
有道翻译 API：需先用client_id+client_secret换取access_token，再 POST 翻译请求；access_token有效期短，不适合长期硬编码 -
腾讯翻译君 API或阿里云翻译 SDK：均有对应 uni-app 兼容的 request 封装示例，但都要求服务端参与密钥管理
关键提醒：所有翻译请求都必须避开在前端代码中明文写死密钥——否则极易被反编译提取，导致配额被盗刷。建议统一走自有云函数中转。
uni.request 调用时容易踩的坑
即使走网络 API，也会遇到典型问题：
- HTTPS 必须启用：iOS App Store 强制 ATS，HTTP 地址会直接失败，确保 API 域名支持 TLS 1.2+
- Android 10+ 默认禁用 cleartext traffic：若测试环境用 HTTP，需在
AndroidManifest.xml中显式配置android:usesCleartextTraffic="true"（仅调试用） - 百度 API 返回字段不稳定：
res.data.trans_result[0].dst可能为空，应加判空和 fallback，例如：res.data?.trans_result?.[0]?.dst || text - 中文输入含空格或标点时，URL encode 不彻底会导致乱码：务必用
encodeURIComponent(text)包裹q参数
真正在 App 端“调用系统翻译”的路子不存在；所谓“系统级体验”，只能靠 UI/UX 模拟（比如仿照系统弹窗样式 + 自家 API 响应），底层仍是网络请求。这点容易被宣传话术误导，开发前务必确认技术边界。
