云部署后邮件全崩？SMTP端口封锁的隐形陷阱

本地测试完美的邮件功能，部署到云端就彻底失效——这不是你的代码问题，而是一场针对垃圾邮件的"无差别打击"。

去年我做用户注册系统时，Nodemailer配Gmail在本地秒发邮件。上线Render后，整个OTP流程直接瘫痪。查日志没有报错，服务状态全绿，邮件就是发不出去。

真相藏在云厂商的防火墙规则里。Render、Heroku、DigitalOcean、AWS这些平台每天要对抗自动化垃圾邮件攻击——恶意用户批量注册免费服务器，瞬间喷出数百万封垃圾邮件。一旦放任，整个IP段会被Gmail、Outlook集体拉黑。

它们的防御策略简单粗暴：免费档和入门档的服务器，出站流量强制封锁25、465、587三个SMTP端口。你的应用不是"发送失败"，是根本连不上邮件服务器，连接请求在底层就被静默丢弃。

绕过方案的核心是放弃SMTP直连，改用HTTP API。Brevo（原Sendinblue）提供REST接口，邮件通过HTTPS走443端口——这是云厂商不可能封锁的通道，也是浏览器和API通信的默认路径。

改造后的流程：用户触发邮件 → 你的服务器调Brevo的HTTP端点 → Brevo用自己的基础设施完成SMTP投递。云厂商的端口封锁完全失效，送达率反而更高——专业邮件服务商的IP信誉和反垃圾策略，远胜个人服务器。

技术实现上，用Node原生的fetch替换Nodemailer的SMTP传输层，把邮件内容打包成JSON POST到Brevo的/v3/smtp/email端点。认证从SMTP的用户名密码，变成API Key的Bearer Token。Express控制器的改动不超过20行。

这个方案的成本结构也更合理：Brevo免费档每天300封，足够中小项目起步；按需付费后单价低于自建SMTP服务器的维护成本。更重要的是，你的应用不再绑定特定云厂商的网络策略，迁移时邮件模块零改动。

端口封锁是云时代的隐性基础设施约束，识别它、绕过它，而不是硬碰硬——这是后端部署的务实哲学。