關於本影片

本影片中的回應是真實的 API 回應。API 金鑰需要付費帳號。

影片文字稿

1. 00:00在伺服器上檢查

   在註冊表單送出時，於伺服器上檢查這個地址，把無法接收郵件的拒於門外。註冊表單送出後，你的伺服器把地址傳送到 /verify/single，讀取狀態，然後做出決定。瀏覽器從不與 API 通訊。有一條簡單的規則。拒絕 invalid，因為那個信箱不存在。拒絕 disposable，因為那是用完即丟的收件匣。放行 role、catch-all 和 unknown。這些可能屬於真實的人。為什麼要在伺服器上？放在瀏覽器程式碼裡的金鑰會發給每一位訪客，任何人都可以用它花掉你的積分。金鑰隨付費帳號提供，所以請保密。

2. 00:41Next.js

   在 Next.js 裡，把檢查放進 route handler。它從伺服器環境讀取金鑰，傳送電子郵件，當狀態是 invalid 或 disposable 時回傳帶訊息的 422。看看其中的關鍵。如果呼叫失敗或逾時，status 為空，這段程式碼會放行這次註冊。這是這個範例裡做出的選擇。如果你比較想攔截，就在那裡回傳一個錯誤。

3. 01:04React

   React 執行在瀏覽器裡，所以它從不持有金鑰。表單送到你自己的路由，收到 422 時顯示訊息。在 Django 裡，從表單的 clean_email 呼叫 Python SDK。對 invalid 或 disposable 拋出驗證錯誤，Django 會把它顯示在欄位旁邊。

4. 01:21Laravel

   在 Laravel 裡，寫一條驗證規則。HTTP 用戶端用設定裡的金鑰送出地址，對同樣這兩種狀態，規則會失敗。連線錯誤則直接回傳，所以表單仍然會通過。

5. 01:34Go

   在 Go 裡，標準函式庫就夠了。這個處理函式呼叫 API，記錄結果，對 invalid 或 disposable 回覆 422。來執行一下。四筆註冊進來。support 和 Leo 的地址收到歡迎信。捏造的 Gmail 地址和 Mailinator 地址收到 422 訊息。伺服器日誌顯示了原因：role、catch-all、invalid 和 disposable。而且每一行都顯示 credits_used 為零。今天稍早我們在這個帳號上檢查過這四個地址。如果同一個地址在 24 小時內再次進來，你不會被重複收費。使用者在密碼欄位裡改正了拼字錯誤再次送出，也不會產生額外費用。

6. 02:15下一步

   這五種都使用同一個端點。欄位和狀態在 billionverify.com/docs 有文件說明。每天使用帳號即可獲得 20 個免費積分，每月上限 600 個，不需要信用卡。前往 billionverify.com 開始使用。

本影片中展示的工具

• 使用者註冊時的信箱驗證:使用者體驗最佳實踐與實作指南
• 為什麼在 2026 年驗證使用者註冊郵箱至關重要