Article · Writing
用 n8n 設計電子報訂閱流程：一份歷史實作紀錄
記錄一套以 n8n 串接資料庫與郵件服務的電子報訂閱流程，並說明它與目前網站 Newsletter Subscription 能力的差異。
Evidence trail
Provenance
這篇內容的 canonical URL 是 /writing/n8n-automated-blog-subscription-system/，發布日期為 2025年7月5日。
相容的歷史路徑：/posts/n8n-automated-blog-subscription-system/
文章目錄
歷史內容：本文記錄 2025 年以 n8n 建立的實作流程。它不是目前網站 Newsletter Subscription 的產品說明，也不代表目前網站已經能完成訂閱、確認、收信與退訂。
很多「訂閱電子報」的教學只展示一個表單，但真正困難的是表單送出之後：如何阻擋重複請求、確認收件者擁有該信箱、在寄信失敗時保留可追查的狀態，以及讓收件者可以安全離開。這篇文章從一套已經做過的 n8n 流程回頭整理這些問題。
先把訂閱拆成四個事件
n8n 是以節點組成工作流程的自動化平台。這套歷史實作沒有把「訂閱」當成一次資料庫寫入，而是拆成四個事件：送出訂閱請求、點擊確認信、發送新文章通知，以及使用者退訂。這樣拆開之後，每個事件都能有自己的驗證條件，也比較容易定位失敗發生在哪裡。
下面的流程圖是原始工作流的快照。它回答的不是「n8n 有多少節點」，而是「一個信箱如何從待確認狀態走到可收信狀態，又如何離開」。
為什麼不能收到信就立刻加入訂閱名單？
因為送出表單的人不一定擁有那個信箱。如果請求一到就寫入正式訂閱表，任何人都可以把別人的地址加入名單。這套流程採用雙重確認（Double Opt-In）：先把請求放進暫存資料，寄出含有臨時 token 的確認信；只有收件者點擊仍在期限內的連結，才會成為正式訂閱者。
在確認之前，流程先做兩層便宜的檢查：
- 以 IP 和時間窗限制過於頻繁的請求，避免同一個端點被重複觸發。
- 檢查信箱格式與正式訂閱表，將格式錯誤、已訂閱與新請求分流。
這些檢查只能降低濫用與重複資料，不能證明信箱屬於請求者；所有權仍要由確認信完成。
臨時 token 解決了什麼問題？
確認連結不直接把信箱當作身分。流程會建立一個隨機性足夠的臨時 token，並把 token、信箱與到期時間放進 pending_confirmations。使用者點擊連結時，查詢同時確認 token 存在且尚未過期：
SELECT email
FROM pending_confirmations
WHERE token = $1 AND expires_at > NOW();
查詢到有效資料後，流程才會把信箱寫入正式訂閱表，產生日後退訂所需的 token，最後刪除暫存確認資料。這個順序很重要：臨時 token 只能使用一次，正式退訂 token 也不需要把信箱暴露在 URL 裡。
發送通知其實是另一個工作流
完成訂閱不等於完成電子報。原始實作把發送拆成三個步驟：從 GitHub 讀取符合日期的文章 front matter、查詢已確認的訂閱者，再把文章與收件者組成待發送項目。寄送時逐封處理，中間加入等待，並在信件中附上每位收件者自己的退訂連結。
這種設計可以說明「內容、受眾、投遞」三者是不同責任，但不能直接推出它具備今日服務需要的可靠性。原文沒有提供長期寄送成功率、重試策略、冪等鍵或完整 production 監控，因此這裡把它當成個人實作的設計紀錄，而不是可直接套用的郵件服務保證。
這套歷史流程和目前網站是什麼關係？
沒有直接關係。現行網站的 Newsletter Subscription 是另一個 Site Capability，必須在 production 完整驗證「subscribe → confirm → receive exactly once → unsubscribe」後才能標記為 live。截至 2026-09-20，能力仍是 planned，首頁表單存在，但 production 的 subscribe route 尚未可用。
因此，本文中的 n8n webhook、Hugging Face、Supabase、Gmail 節點與舊流程圖，都只能描述當時的做法；它們不是目前網站的實作承諾。若要理解另一個與部署有關的歷史背景，可以閱讀在本地 Docker 執行 n8n，並用 Cloudflare Tunnel 接收 Webhook，但該文同樣需要遵循當前官方文件重新核對版本。
這份紀錄留下的工程界線
這套流程最值得保留的不是「完全免費」或某個服務名稱，而是幾個可移植的判斷：先驗證再寫入、把待確認與正式訂閱分開、讓退訂不必暴露信箱，以及把發送工作從訂閱工作中拆開。
同時也要保留證據界線。本文的流程圖與介面截圖來自原始文章；它們證明當時曾設計或操作過這條路徑，並不證明目前的服務仍可用，也不證明它符合今天的安全、隱私、郵件投遞或法規要求。若要把它重新變成可上線能力，下一步必須是新的 production E2E 驗證，而不是把歷史文章的狀態改成 current。