测试无密码登录，告别收件箱混乱
在演示中，无密码登录看起来很简单。用户输入电子邮件，收到一个魔术链接（magic link），然后会话开始。
在 staging 环境中，这个流程会变得很混乱。链接会掉进共享收件箱或旧的别名邮箱中，从而产生大量干扰信息。
你必须将无密码身份验证视为一个完整的系统。你需要测试 JavaScript 客户端、Node.js 后端、邮件投递以及会话管理。如果你忽略了收件箱环节，即使你的 API 测试通过了，你可能仍然发布了一个存在缺陷的流程。
常见的失败情况包括：
- 后端在重试后发送了两个链接。
- 邮件指向了错误的 Host。
- 旧链接的有效期超过了预期。
- 前端在 Cookie 设置之前就将用户标记为已登录。
为每次测试运行使用隔离的收件箱。这可以防止测试数据泄露到团队邮箱中。在 staging 环境中使用一次性电子邮件服务，以保持每次运行的独立性。
隔离让调试变得简单。如果测试失败，你应该能看到一个收件箱和一个用户旅程。你应该能准确知道哪条消息属于哪个构建版本。
一个好的测试会按顺序检查以下步骤：
- 登录请求成功，且不会泄露账户是否存在。
- 恰好收到一个全新的魔术链接。
- 链接的 Host 与你的 staging 域名匹配。
- 链接启动了一个有效的会话。
- 重复使用同一个链接会失败。
- 应用无需手动刷新即可更新导航状态。
在 Node.js 端，为你的日志附加一个关联 ID（correlation ID）。从请求到邮件发送，再到最终的会话，全程使用它。这有助于你在邮件延迟或重复时快速定位 Bug。
不要用邮件测试取代所有的测试。使用快速的单元测试来验证 Token 逻辑和会话规则。使用邮件路径来证明真实的用户体验是通畅的。
发布前的检查清单：
- 一次登录请求仅创建一个活动的链接。
- 在 staging 环境中，最新的邮件易于解析。
- 链接在正确的 Host 上工作。
- 链接无法被重复使用。
- 注销并重新登录会创建一个全新的、干净的 Token。