客戶原本的 footer 有一個「訂閱」表單，但它只是版型——填了 email 什麼都不會發生。我們要把它變成真的能用：收 email、寄歡迎信、發新文章時通知每位讀者、還要能安全退訂。拆開來，其實是三條各自獨立的流程。

決策一：先收信，還是先能寄？

我們刻意把「收集並存下 email」和「實際寄信」拆成兩層。前者不依賴任何寄信服務就能上線——就算還沒設好 SMTP，訂閱一樣寫得進資料庫，信件只是印到後台日誌。這讓客戶可以先讓表單真的能用，寄信之後再接，不必卡在一起。

決策二：Gmail SMTP 還是專門寄信服務？

客戶剛起步、訂閱數不高，我們選了最省事的 Gmail SMTP（用應用程式密碼即可），並在設計上留好退路：哪天量大了，只要換掉寄信這一層就能升級到 Resend／SES。

決策三：要不要「雙重確認」？

對一個個人旅遊部落格，我們用單重訂閱：填了 email 就直接算訂閱、並寄一封歡迎信，不強迫再點確認信。門檻低、體驗順；但退訂一定要做好——這也是後面資安那篇的重點。

最後這套包含哪些零件

整個訂閱系統其實是六個小零件組起來的，每一個都對應這個系列裡的一篇筆記：

誠實的取捨

• 背景廣播是行程內佇列，容器重啟會漏掉沒送完的；我們用「先標記已寄」換取「不會整批重寄」。
• Gmail 有每日上限，訂閱數長大就要換寄信服務——但那是「幸福的煩惱」，留給有需要的那天。
• 每個零件都可獨立驗證，正是這樣我們才敢一塊一塊接、一塊一塊上線。