邮件登录与回调验证

邮件服务本身是上层集成的事。移动端只关心一件事：用户点了邮件里的链接后，能不能回到 App 并顺利完成登录或验证。

你将学到

• Magic Link 从邮件到 App 的完整回调链路
• 验证邮件、OAuth 回调各自需要检查什么
• 链接过期时怎么给用户明确反馈
• 为什么真机测试比模拟器更可靠

回调链路

整条链路可以这样理解：

1. 用户收到邮件 -- Magic Link 或验证邮件，由服务端发出
2. 点击链接 -- 在浏览器或邮件客户端里打开
3. 回到 App -- 通过 scheme 或 deep link 跳回 App
4. 完成登录 -- session 写入，用户状态更新

中间任何一环断裂，用户都会卡住。所以移动端需要验证的不是邮件怎么发的，而是链接能不能把用户带回 App，回来之后状态是否正确。

端侧要验的

测试 Magic Link 时，用真机发一封真实的验证邮件，从邮件客户端点链接回到 App，确认 session 已经生效。模拟器和 curl 只能覆盖一部分场景。

对于链接过期的情况，确保 App 能显示友好的提示而不是技术错误码，并提供重新发送的入口。用户不应该需要手动复制链接或重新输入邮箱。

为什么真机测试很重要

模拟器能测大部分逻辑，但邮件回调有几个地方只有真机才能验证：

• 真实邮件客户端对链接的处理行为
• 系统级的 scheme 跳转和 App 唤醒
• Universal Links 在真机上的匹配规则

建议在开发中期就开始真机测试，不要等到提交商店前才发现回调链路不通。

常见问题排查

如果 Magic Link 回调不工作，按顺序检查：

1. app.json 里的 scheme 是否和服务端 NATIVE_APP_SCHEME 一致
2. .env.local 里的 EXPO_PUBLIC_APP_SCHEME 是否和 app.json 一致
3. 开发环境用的是 development build 而不是 Expo Go（Expo Go 不支持自定义 scheme）
4. 邮件里的链接格式是否正确，scheme 前缀有没有被邮件客户端改写

下一步

邮件回调验证通过后，进入 Deep Link 与外部跳转 了解 scheme、Universal Links 和分享链接的处理。