邮箱生态调研2026
内容提要
该文调研了2026年将邮箱作为应用存储（BYOS）的可行性。作者发现，主流邮箱已全面转向OAuth 2.0，弃用明文密码，导致用户授权流程复杂。对比Gmail、Outlook、Yahoo、iCloud及国内邮箱，开发者面临审核门槛高、操作繁琐等问题。最终结论是此方案不切实际，建议放弃。
延伸解读
OAuth 2.0 的开发者门槛
主流邮箱全面转向 OAuth 2.0 后，开发者面临的不只是技术适配，还有审核门槛。Gmail 的 restricted scope 要求正式对外必须通过 OAuth 验证和安全评估，且每年复审，未过审只能用于测试用户或内部使用。相比之下，Outlook 和 Yahoo 的审核门槛较低，但用户操作流程各有差异。这意味着，选择邮箱作为存储时，开发者需评估审核成本，否则可能长期停留在测试阶段。
应用专用密码的局限
应用专用密码或授权码看似是绕过 OAuth 的捷径，但实际使用中问题不少：用户需先开启 2FA，再进入设置页生成 16 位密码，平均耗时 5~15 分钟，且容易因未开 2FA、改密吊销、粘贴空格等问题产生客服工单。Google 官方已明确不推荐应用专用密码，微软和雅虎也逐步封死明文密码，这条路只会越来越窄，不适合作为长期方案。
国内邮箱的差异化
国内邮箱（QQ、163/126）目前不支持 OAuth，仅提供授权码，且无官方公开 API 文档，开发者只能依赖实操惯例。虽然授权码生成流程相对简单（2~3 分钟），但缺乏标准化和官方支持，风控策略不透明，可能带来稳定性风险。对于需要跨平台一致性的应用，国内邮箱的接入体验与国外主流邮箱存在明显差距。
Q&A
2026年将邮箱作为应用存储（BYOS）是否可行？
不可行。主流邮箱已全面转向OAuth 2.0，弃用明文密码，开发者面临审核门槛高、用户授权流程复杂等问题，因此该方案不切实际，建议放弃。
Gmail、Outlook、Yahoo、iCloud等主流邮箱的开发者接入方式有何不同？
Gmail和Outlook使用OAuth 2.0（SASL XOAUTH2），Yahoo使用OAuth 2.0（SASL OAUTHBEARER），iCloud支持OAuth或应用专用密码，而QQ邮箱和163/126邮箱没有OAuth，仅提供授权码。
使用Gmail的OAuth 2.0作为开发者接入有哪些审核门槛？
Gmail的scope是受限的，正式对外必须通过OAuth验证和安全评估，且每年复审；未过审只能用于不超过100个测试用户或内部使用。
用户使用应用专用密码或授权码的流程是怎样的？
用户需要先开启2FA（Google和Apple强制），然后进入设置页面生成16位密码或授权码，再回到App粘贴。整个过程平均需要5到15分钟，且容易出错，是客服工单的主要来源。
Gmail的IMAP服务器有哪些硬性限制？
Gmail的IMAP服务器为imap.gmail.com:993，容量15GB（与Drive和相册共享），单封邮件大小限制25MB，支持15个并发连接，会话约24小时，明文密码已废除，需使用OAuth或应用专用密码。
为什么说把产品押在应用专用密码上是逆政策而动？
因为Google官方明确表示应用专用密码不推荐且不必要，方向是逼大家走OAuth；同时微软和Yahoo已先后封死明文密码，应用专用密码这条路只会越来越窄。
