本地測試完美的郵件功能，部署到云端就徹底失效——這不是你的代碼問題，而是一場針對垃圾郵件的"無差別打擊"。

去年我做用戶注冊系統(tǒng)時，Nodemailer配Gmail在本地秒發(fā)郵件。上線Render后，整個OTP流程直接癱瘓。查日志沒有報錯，服務狀態(tài)全綠，郵件就是發(fā)不出去。

真相藏在云廠商的防火墻規(guī)則里。Render、Heroku、DigitalOcean、AWS這些平臺每天要對抗自動化垃圾郵件攻擊——惡意用戶批量注冊免費服務器，瞬間噴出數(shù)百萬封垃圾郵件。一旦放任，整個IP段會被Gmail、Outlook集體拉黑。

它們的防御策略簡單粗暴：免費檔和入門檔的服務器，出站流量強制封鎖25、465、587三個SMTP端口。你的應用不是"發(fā)送失敗"，是根本連不上郵件服務器，連接請求在底層就被靜默丟棄。

繞過方案的核心是放棄SMTP直連，改用HTTP API。Brevo（原Sendinblue）提供REST接口，郵件通過HTTPS走443端口——這是云廠商不可能封鎖的通道，也是瀏覽器和API通信的默認路徑。

改造后的流程：用戶觸發(fā)郵件 → 你的服務器調Brevo的HTTP端點 → Brevo用自己的基礎設施完成SMTP投遞。云廠商的端口封鎖完全失效，送達率反而更高——專業(yè)郵件服務商的IP信譽和反垃圾策略，遠勝個人服務器。

技術實現(xiàn)上，用Node原生的fetch替換Nodemailer的SMTP傳輸層，把郵件內容打包成JSON POST到Brevo的/v3/smtp/email端點。認證從SMTP的用戶名密碼，變成API Key的Bearer Token。Express控制器的改動不超過20行。

這個方案的成本結構也更合理：Brevo免費檔每天300封，足夠中小項目起步；按需付費后單價低于自建SMTP服務器的維護成本。更重要的是，你的應用不再綁定特定云廠商的網絡策略，遷移時郵件模塊零改動。

端口封鎖是云時代的隱性基礎設施約束，識別它、繞過它，而不是硬碰硬——這是后端部署的務實哲學。