Auth.js 官方 Email Provider 指南写明，验证邮件中的令牌默认有 24 小时可供用户点击；但你不能把这个默认值直接当作项目验收结果，具体行为仍要核对所用版本和配置。结论：适合用能实际读取邮件的受控测试收件地址验收完整登录闭环；不适合只凭发送请求成功就判定登录可用。收件、链接回调和会话建立是不同结果，必须分别留证。
接入 Auth.js Email Provider、需要确认自家应用能否发出并处理登录链接的开发者。
负责邮件回归的 QA：需要核对收件内容、链接结果和失败分支。
维护预发环境的独立开发者或小团队：需要避免测试邮件进入个人或正式工作邮箱。
验收前先固定环境与通过条件
Auth.js 官方文档将 Magic Links 列为邮件认证方式，Email Provider 参考也提供 maxAge 等配置项。因此，文档中的默认流程和部署后的实际行为不能混为一谈。先记下项目所用 Auth.js 版本、运行环境、适配器及相关配置，再写清本次验收的通过条件。
至少区分以下三个关口：
- 发送请求已处理：应用走到了发信逻辑，或邮件服务接受了发送请求。这不能证明目标收件箱里已经有邮件。
- 邮件实际到达：你能在受控测试收件箱中找到这封邮件，并确认收件地址、主题和正文都对应本次操作。
- 登录闭环完成：链接被应用正确处理，用户进入预期页面，应用侧也能读取到预期会话。
另一个容易漏掉的配置边界是验证令牌的存储与查找。即使你的会话策略使用 JWT，也不能因此跳过令牌存储配置；若使用自定义数据库结构，要确认适配器实际连接到了保存验证令牌的表。Auth.js 的 Drizzle 适配器指南会单独列出 Magic Link 所需的 verificationTokensTable。
场景例子：你在本地页面提交测试地址，界面提示“请检查邮箱”，服务日志也显示发信函数已调用；如果收件箱没有邮件，这只能说明请求走到了某一步，不能证明收件链路或登录链路已通过。
按清单准备一次可追踪的测试
每次验收开始前，先勾选以下项目。这样邮件延迟、环境串线或账号状态异常时，你能从记录中定位差异，而不是靠重复点击碰运气。
- [ ] 只在自家应用或获授权的测试、预发环境操作，并明确本次运行环境。
- [ ] 选择你能实际打开邮件正文和链接的测试收件地址；记录该地址是否能继续用于重发与复测。
- [ ] 记下测试账号、运行标识、触发时间和预期结果页，避免把旧邮件认成本次新邮件。
- [ ] 确认当前部署的站点地址、认证路由、邮件模板和适配器配置，分别以项目实际设置为准。
- [ ] 预先定义成功证据：收件箱中的邮件、链接最终指向的环境、回调结果，以及服务端或应用可见的会话状态。
- [ ] 为重复点击、再次申请和无效或过期链接安排独立测试，不把它们和首次登录混成一个结果。
如果这次只验证邮件模板是否能触发，拦截式测试可能已经够用；但如果验收要求确认真实邮件到达、链接可打开，你需要能读取邮件内容的收件方式。选择临时邮箱还是长期地址，可以参考临时邮箱与邮箱别名的用途差异：前者更适合短期测试，后者更适合需要持续找回或留存通知的账号。
从登录入口触发请求并关联本次邮件
打开自家应用的登录入口，输入本次记录的测试账号，按项目实际界面提交 Magic Link 请求。此时不要只记“页面显示已发送”，还要记下运行标识与环境，例如本地、预发或生产；否则多个测试地址和近似时间的邮件很容易混淆。
Auth.js Email Provider 流程包含生成验证请求、发送邮件和后续处理链接等环节；具体发送参数应对照你采用的 Provider 配置与项目实现。官方 Email Provider API 参考列出 sendVerificationRequest 相关参数，包括收件标识、链接 URL 和过期时间；这些信息适合用来核对项目生成的邮件，但并不代表邮件已到达。
测试地址到底有没有收到邮件，应该看什么？
打开受控测试收件箱，按测试地址、主题和触发时间定位邮件，并确认它属于刚才记录的运行。发信日志或邮件服务接受请求的记录只证明发送链路上的一个节点；若邮件缺失，先分别检查应用是否执行发信逻辑、邮件服务的投递记录和收件箱的垃圾邮件分类，不要直接把问题归因于登录回调。
在收件箱核对地址、正文与环境链接
邮件到达后，不要急着点击。先确认收件地址确实是本次测试地址，正文中包含预期的登录说明，链接主机名和路径属于当前测试环境，而不是生产站点或另一个预发部署。保存邮件时要注意脱敏：测试记录不应公开完整令牌或可直接登录的链接。
邮件里的链接跳错环境，先核对哪些配置？
先比对当前测试部署的公开站点地址与邮件中链接的主机名，再核对认证路由、回调路径以及模板是否使用了旧的环境变量或缓存配置。Auth.js 的安装与路由配置说明指出，应用需按自己的框架接入对应路由；不同框架的处理入口不应被想当然地套用成同一路径。
验收邮件本身也有实际成本：收件地址不可持续使用时，你可能无法再次查看旧邮件；邮件模板把令牌或链接完整写进日志，也会扩大测试凭据暴露面。把地址可读性、邮件留存和日志脱敏一起考虑，才不会把“收到一封邮件”误当成一套可重复的验收流程。关于测试数据中真实邮箱与个人信息的取舍，可继续看测试时隔离邮箱与个人信息的隐私做法。
点击链接后分别验证回调和会话
从刚收到的邮件打开链接，记录浏览器最终落到的地址、页面提示和当前环境。页面跳转只是表象：还要在应用可验证的位置确认用户处于登录状态，例如读取受保护页面的服务端会话，或检查一个要求已认证身份的应用接口是否返回预期结果。Auth.js 的资源保护指南提供了通过 auth() 获取会话并保护资源的示例；你应采用项目实际框架对应的检查方式。
点击登录链接后，怎样确认用户真的登录了？
同时检查回调是否成功处理、目标页面是否正确，以及服务器或应用读取到的用户身份是否对应测试账号。若只看到跳转，却没有受保护资源访问成功或会话状态证据，结果应记为“回调已跳转，登录未证实”，不要算作完整通过。
重发、再次点击与失效链接单独回归
分别执行再次申请、旧邮件链接再次打开，以及项目实际能构造的无效或过期链接测试。每次记录具体配置与观察结果，不要预先写死“重新申请后旧链接一定失效”或“所有版本固定在某个时长过期”。Auth.js 的适配器 API 参考说明，useVerificationToken() 会取回并删除验证令牌，使其只能使用一次；但这不意味着你可以跳过对自家适配器、请求流程和错误反馈的验证。
重复点击时要验收什么？
检查第二次打开同一链接后，应用是否拒绝再次使用、是否仍错误地显示登录成功，以及错误提示是否清楚但没有泄露令牌或内部细节。重新申请后，再按项目配置检查旧邮件和新邮件各自的处理结果；把这些结果作为你应用的回归基线，而不是推广成 Auth.js 的通用默认行为。
失败分支也要有明确结论：验证令牌不存在、已过期或与请求账号不匹配时，应用应阻止不符合预期的登录，并向用户给出可理解的下一步，例如重新申请链接。究竟显示什么提示、跳到哪里，由项目实现决定；验收时应确认既没有静默失败，也没有把失败页面伪装成已登录状态。
汇总证据并划定验收结论
最终记录至少包括发送请求的日志或状态、收件箱中的邮件、链接最终指向的环境、回调结果和登录后的会话证据。把“邮件未到”“链接错环境”“回调失败”“会话未建立”分开归类，可以避免只修一个环节，却误以为整条链路已经恢复。
- ✅ 完整通过：本次邮件实际到达，链接指向预期环境，回调成功，应用确认了正确账号的会话；重复使用与失败分支也按本项目预期处理。
- ⚠️ 部分通过：发送请求成功但没有收件证据，或链接已跳转但会话未确认。记录已通过的节点，剩余部分继续补测。
- ❌ 未通过：链接进入错误环境、验证失败却被误判为成功，或应用没有按项目预期拒绝无效链接。
受控测试收件地址能帮助你检查邮件正文和登录链接，但不能证明生产环境的每个收件服务都会正常投递，也不能代替目标用户邮箱的预发补测。若你只是在自家应用中临时注册测试账号、打开邮件确认链接，TMPFox 页面提供无需注册、即时收信和到期前延长等能力；你可以先确认当前地址的可用状态，再决定是否用于本轮验收。若账号需要长期找回、持续收信，或你需要反复使用同一邮箱身份，就选稳定的长期邮箱方案，而不要把临时收件地址当成生产账号邮箱。