背景：註冊流程中最惱人的斷點
幾乎每個人都經歷過這種流程：在網站輸入電子郵件、按下註冊，接著切換到收件匣、找到驗證信、複製一次密碼（one-time code）或點擊 magic link，再回到原本的網站。這一來一回的情境切換（context switch）不僅拖慢速度，更常常直接讓使用者放棄註冊。除此之外，驗證信還可能被延遲投遞、被歸入垃圾郵件，甚至根本沒有送達，而使用者從畫面上完全無法分辨信是「慢了」還是「丟了」。根據 InfoQ 在 2026 年 10 月 28 日的報導，Google 針對這個長期痛點提出了解法：Email Verification API。
核心內容：瀏覽器居中協調的三方驗證模式
Email Verification API 是一項在 WICG（Web Incubator Community Group，W3C 旗下負責孵育新網頁標準提案的社群）討論中的提案，Google 已於 Chrome 150 的桌面版展開 origin trial（源點試驗，一種讓開發者能在正式標準化前於真實網站測試新 API 的機制），Gmail 是第一個參與的信箱供應商。
這套機制的架構包含三方：需要驗證訪客信箱的網站稱為 verifier（驗證方），使用者的信箱供應商稱為 issuer（簽發方），而瀏覽器則居中協調。如果使用者已經登入自己的信箱供應商，瀏覽器就能在背景取得一個經過簽署的 token（簽章權杖），自動填入表單；網站的伺服器收到表單後，只需驗證這個 token 的簽章，即可確認該使用者確實擁有這個信箱，全程不必寄出任何一封郵件。
實作方式與開發生態
對前端開發者來說，接入相當輕量：在電子郵件輸入欄加上 autocomplete 提示，並放一個隱藏欄位承載與工作階段綁定的 nonce（一次性隨機數，用來防止重送攻擊），分別以 autocomplete="email" 與 autocomplete="email-verification-token" 標記即可。較重的部分落在伺服器端：必須向信箱供應商取得公鑰，驗證 token 的簽章是否有效。專注於郵件服務的開發者 Phil Nash（任職於 Resend）已撰寫了完整流程解析，並釋出 npm 套件與 Next.js 範例，協助處理解析與驗證的工作。
社群反應：肯定與質疑並存
這項提案在 Hacker News 上引發熱烈討論。有開發者直言，註冊到一半跳出來開收件匣是「最糟糕的情境切換」，並估計驗證信流程讓他們損失了「數十甚至數百個」未完成的註冊。另一位開發者補充，驗證信經常被擋下或過濾到垃圾信夾，因此移除這個環節是實質的改善。
不過質疑聲音同樣存在。有評論者認為 Google 主張的隱私效益相當薄弱：雖然 Google 強調 issuer 不會知道是哪個網站發起請求（因為請求由瀏覽器居中處理），但實務上幾乎所有網站在驗證後都會寄送歡迎信、新手引導與提醒郵件，供應商依然能從中推知使用者的網站活動，隱私保護形同虛設。也有人認為「issuer 無法得知請求來源」對供應商而言是一種功能上的負債而非優勢。仰賴子地址別名（例如 [email protected]）來追蹤各網站寄件來源的使用者，也會在供應商無法為這類別名背書時被迫退回舊流程。另有評論將此 API 與 FedCM（Chrome 先前將聯合身分驗證機制收進瀏覽器的類似舉措）相提並論，認為瀏覽器正持續把身分相關的基礎功能收攏進平台層，長遠來看可能有利於大廠而不利於小型網站。
影響、限制與後續觀察
在 Chrome 搭配已登入的 Gmail 帳號之外，網站仍會退回傳統的確認信流程；既有的語法檢查、MX 記錄與 SMTP 驗證服務，也繼續涵蓋這個 API 無法處理的地址類型。因此這項技術應被視為漸進式增強（progressive enhancement）：在支援的環境下提供更順暢的體驗，不支援時網站功能不受影響。
值得注意的是 API 仍在快速變動。Chrome 十月的更新將試驗擴及 Android 與第三方源點試驗（Chrome 154 起）、把 Sec-Fetch-Dest 的發行值更名為 email-verification，並自 Chrome 156 起回傳與使用者輸入完全一致的電子郵件地址。已經著手測試的團隊需要持續追蹤破壞性變更。整體而言，Email Verification API 直接回應了註冊漏斗中真實存在的流失問題，若最終標準化並獲得更多信箱供應商支持，可望顯著簡化網站的驗證流程；但它能否真正帶來隱私改善、以及把驗證能力集中到瀏覽器層是否健康，仍有待 WICG 從網站、供應商與使用者端收集更多回饋後才會明朗。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。