mailto:协议是App端唤起系统邮件客户端的唯一可靠方式，但Android部分定制ROM（如华为、小米）存在唤起失败问题，iOS较稳定；其不支持附件，主题/正文显示受系统限制，需严格遵循RFC标准编码，参数顺序及URL编码不全易导致失败；uni.navigateTo调用需加fail兜底提示，plus.messaging方案更可控但仅限5+ SDK环境；rich-text中需预处理邮箱为data-email标签并绑定tap事件，或使用mp-html插件；Android静默失败常见，须真机测试并提供复制邮箱备用路径。
mailto: 协议是 App 端唤起系统邮件客户端的唯一可靠方式，但直接用 uni.navigateTo 打开 mailto: 链接在部分 Android 设备上会失败（尤其是华为、小米等定制 ROM），iOS 则基本稳定。别指望它能带附件或保证主题/正文 100% 显示——这是系统级限制，不是代码能绕过的。
mailto: 链接构造必须严格符合 RFC 标准
常见错误是 URL 编码不全或参数顺序错乱，导致主题、正文丢失或唤起失败：
-
to必须是纯邮箱地址，不能带空格或中文，例如mailto:test@example.com - 带参数时，
?后所有值必须encodeURIComponent，尤其subject和body中的换行、空格、中文 - 参数顺序有影响：Android 某些版本只识别
?to=...&subject=...&body=...，cc/bcc支持度更低，建议只用to+subject+body - 示例正确写法：
mailto:test@example.com?subject=encodeURIComponent('订单确认')&body=encodeURIComponent('您好，您的订单已提交。')
uni.navigateTo({ url: 'mailto:...' }) 在 App 端的实际表现
这个 API 是最轻量的唤起方式，但失败率不可忽视：
- Android 上，若设备未设置默认邮件应用，
fail回调会触发，但不会给出明确错误码；常见现象是页面白屏几秒后返回，无提示 - iOS 上成功率高，但若用户从未配置过邮件账户，也会静默失败
- 务必加
fail处理：uni.navigateTo({ url: 'mailto:' + encodedUrl, fail: (err) => { uni.showToast({ title: '未找到邮件应用', icon: 'none' }); }}); - 不要用
uni.redirectTo，它在某些版本中会直接忽略mailto:协议
plus.messaging 方案：更可控但仅限 5+ SDK
如果你的项目已集成 5+ Runtime（即使用 uni-app 的「原生渲染」模式），plus.messaging 提供更细粒度控制：
- 支持设置
to（数组）、subject、body、bodyType（text/plain或text/html） - 回调明确区分成功/失败，失败时
e.message可能含“no email app”之类信息 - 注意：H5 和小程序平台下该对象不存在，需做运行环境判断：
if (typeof plus !== 'undefined' && plus.messaging) { // 使用 plus.messaging} else { // 降级为 mailto: } - 不支持附件，且
body中 HTML 渲染效果取决于目标邮件客户端（如 Outlook for iOS 不渲染<b>）
富文本中邮箱点击的拦截与预处理
rich-text 组件对 mailto: 链接无原生支持，tap 事件无法准确捕获内部链接点击：
- 推荐做法：在渲染前对 HTML 做预处理，把
user@example.com替换为带data-email属性的<span>，再绑定父容器tap事件，通过event.target.dataset.email获取并构造mailto:链接 - 避免用正则全局替换生成
<a href="mailto:...">，因为rich-text会过滤掉href属性或导致样式错乱 - 若内容复杂，改用
mp-html插件，它支持mailto:的自动识别和点击拦截，但需额外引入和配置
fail 里加兜底提示，并考虑提供「复制邮箱」按钮作为备用路径。不同厂商 ROM 对 mailto: 的解析差异比文档写的更大，真机测试不能跳过。 
