在没有收件箱冲突的情况下测试 React 邀请邮件
当邀请流程淹没共享的 QA 收件箱时，预览环境就会失效。
一名测试人员打开了错误的链接。另一名测试人员抓取了旧消息。团队开始争论究竟是 React 代码坏了，还是后端发送了旧数据。
你必须将邮箱视为产品的一部分。如果你的引导流程（onboarding）依赖于电子邮件，那么你的预览环境就需要一套隔离策略。否则，你的反馈循环会变慢。
预览分支中的常见故障模式：
- 邮件链接指向了旧的部署。
- 重试的 API 调用为同一个用户创建了两个邀请。
- UI 接受了邀请，但显示的是旧的会员数据。
- 在另一个人验证分支之前，一名测试人员就使用了该 token。
共享收件箱会导致测试结果不稳定（flaky tests）并降低信任度。
使用这个简单的流程来解决它：
- 在预览环境中使用真实的 React 管理界面创建邀请。
- 使用与生产环境相同的后端路径、模板和 token 逻辑。
- 将邮件路由到一个仅为该次运行而创建的短期收件箱中。
- 在浏览器中打开链接并检查应用状态。
临时邮箱生成器非常适合快速进行分支验证。它们能让你的流程保持简单。
一个好的预览测试必须检查以下事项：
- 邮件包含该分支正确的预览主机地址（preview host）。
- 接收者仅存在一个有效的邀请链接。
- Token 跳转到了正确的 workspace 和角色。
- React 应用无需手动刷新即可更新访问状态。
- 接受邀请后，第二次点击链接应当失败。
不要忘记前端断言（assertion）。后端日志可能显示成功，但客户端可能仍显示待处理（pending）状态。用户会立即注意到这一点。
在从创建邀请到最终激活的过程中添加关联 ID（correlation ID）可以节省时间。这有助于你发现是否因为环境变量的原因导致错误的 host 混入了模板中。
目标并不是在所有地方都使用临时收件箱。目标是隔离真实的邀请路径。这可以在回归问题影响生产环境之前将其捕获。
在信任邀请流程的变更之前，请使用此清单：
- 邮件链接到正确的预览部署。
- Token 映射到正确的 workspace 和角色。
- 第二次点击不会复用同一个 token。
- 接受后的状态在 UI 中直接显示，无需额外的页面跳转。
- 邮箱易于识别和丢弃。