北京
周三下午，一个开发者把 main.ts 跑了二十遍。每跑一次，收件箱里就多一封真实的欢迎邮件。同事用自己的地址测试，也被塞了一堆。Resend 免费额度的计数在往上跳，而如果有人忘了配 RESEND_API_KEY，应用直接崩。
这段代码最初只有几行：引入 Resend 客户端，调用 emails.send，把发件人、收件人、标题、正文塞进去。跑通，邮件一秒后到达。看起来没有任何问题。
问题出在它跑通之后。测试流程需要反复触发注册，真实发信就成了负担。理想状态是：生产环境发真邮件，其他地方只让邮件停在本地，看得见、发不出去。
Mailpit 正好干这件事。它是一个假的 SMTP 服务器，带一个网页界面，应用“发出”的每封信都能在里面读到。用 Docker 一行配置就能起：映射 1025 端口给应用说话，8025 端口给自己看信。启动后打开本地页面，收件箱是空的。
因为 Mailpit 说的是 SMTP，用 Nodemailer 就能连上。于是发信函数里多了一个分支：生产环境走 Resend，其余走本地 SMTP。刷新页面，邮件出现了，问题似乎解决了。
但这段代码读起来有点不对劲。sendWelcomeEmail() 本该只负责“欢迎”这件事，现在它同时知道 Resend、Nodemailer、SMTP 端口和 NODE_ENV。下一个函数 sendPasswordResetEmail() 需要抄一遍同样的 if/else，再下一个也一样。想换第三个服务商，就得在项目里把每个 if 找出来。更隐蔽的是，Resend 客户端在模块导入时就被创建，哪怕这次根本不会用到它——那个“忘了 API key 就崩”的毛病，正是从这里来的。
这就是紧耦合的样子：一封欢迎邮件被粘在两个服务商和一个环境变量上，动其中一个，另外两个都得跟着动。
修法的第一步，是先说清楚需要什么，而不是谁来干。应用真正需要的只有一件事：把邮件发出去。于是定义一个 Mailer 接口，只包含一个 send 方法，参数是收件人、标题、正文。注意这里没有发件人字段——允许从哪个地址发，是服务商知道的事，应用不需要操心。
第二步，给每个服务商一个自己的盒子。ResendMailer 和 MailpitMailer 各自实现 Mailer，各自在构造函数里创建自己的客户端。整个项目里，只有这两个文件知道对应服务商的存在。
第三步，欢迎邮件回到无聊状态。它只接收一个 Mailer，调用 send，然后结束。导入列表里没有 Resend，没有 Nodemailer，没有 process.env。
第四步，把“选谁”这件事收到唯一的入口。应用启动的地方判断一次环境，生产环境就 new 一个 ResendMailer，否则 new 一个 MailpitMailer，然后把它传给发信函数。本地跑，邮件进 Mailpit 的网页界面，不需要 API key，不需要联网；带上生产环境变量跑，同一份代码、同一个函数，收件箱里收到真信。
这样改完，账可以一笔一笔算：
sendWelcomeEmail()只剩一个变更理由——欢迎邮件的内容本身，与服务商和环境无关。NODE_ENV的判断在整个项目里只出现一行。再加十种邮件，这行也不用动。- 想接第三个服务商，写一个新类，改
main.ts里的一行，其他代码甚至不知道发生过这件事。 - Resend 的 SDK 只被
ResendMailer导入。不创建它，就永远不碰它，那个崩溃顺带消失了。 - 测试变得极其简单：传一个把邮件塞进数组的
Mailer，直接对数组断言，不需要 mock 库，不需要网络。
这就是松耦合的实际含义。欢迎邮件和 Resend 原本是粘在一起的，现在它们只是两个碰巧都认可 Mailer 这份小契约的东西。欢迎邮件不知道 Resend 存在，Resend 也不知道欢迎邮件存在，main.ts 是唯一把它们介绍给彼此的角色。
为两行邮件加这些结构，看起来像多余的仪式。但等到某个周五下午必须换掉服务商、而只有一处文件需要改的时候，这套东西的价值就显出来了。
顺带一提，Resend 免费额度有个限制：只能从 onboarding@resend.dev 发给你注册时用的那个邮箱。测试时把收件人设成它，就不用先验证域名。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
