uni-id-pages 配置 email 這件事我前陣子在新項目里又完整走了一遍。說實話uni-id-pages 這套用戶體系已經(jīng)很成熟了但郵件驗證碼這塊的配置一直比較分散官方文檔有、插件市場示例也有可真到自己上手時還是會遇到“配置了但發(fā)不出去”“驗證碼一直提示錯誤”“測試郵箱收不到郵件”這種問題。這篇文章把我這次的實操過程、配置細(xì)節(jié)、以及踩過的坑完整記錄下來給準(zhǔn)備在 uni-id-pages 里接郵箱驗證碼登錄/注冊/找回密碼的朋友做一個可以直接抄的參考。1. uni-id-pages 里郵箱驗證碼到底用在哪先說清楚 uni-id-pages 是什么。它是 uni-app 生態(tài)里的一個用戶登錄/注冊/找回密碼的頁面插件配合 uniCloud 云服務(wù)端的 uni-id-co 云對象使用提供賬號密碼、短信驗證碼、郵箱驗證碼、微信一鍵登錄、Apple 登錄等能力。它不是一個簡單的頁面而是一整套用戶認(rèn)證身份方案的前端部分后端邏輯在 uni-id-co 云對象里。1.1 這套東西的運行邏輯我在項目里用 uni-id-pages最核心的一個原因就是它把前端頁面、云對象、uni-id 公共模塊這三層全打通了。前端頁面負(fù)責(zé)收集用戶輸入、調(diào)起驗證碼發(fā)送和登錄請求uni-id-co 負(fù)責(zé)真正執(zhí)行發(fā)郵件、校驗驗證碼、創(chuàng)建賬號、返回 tokenuni-id 公共模塊則負(fù)責(zé)通用的用戶表結(jié)構(gòu)和權(quán)限校驗。所以配置 email 不只是在前端改改頁面還需要把云端的配置、公共模塊的參數(shù)一起改到位。整個郵箱驗證碼的調(diào)用鏈路是這樣的用戶在 uni-id-pages 的登錄頁選擇郵箱驗證碼登錄輸入郵箱后點擊“獲取驗證碼”前端調(diào)用云對象 uni-id-co 的 sendEmailCode 方法云對象校驗郵箱格式后使用配置好的 SMTP 服務(wù)把郵件發(fā)出去郵件里帶上隨機驗證碼用戶收到驗證碼后在表單里輸入前端再調(diào)云對象的 login 方法場景里是 email 登錄云對象核對驗證碼和郵箱是否匹配匹配則創(chuàng)建或登錄賬號返回 token 給前端存起來。這套鏈路本身不復(fù)雜但每一環(huán)都可能出問題。SMTP 配置錯了郵件發(fā)不出驗證碼發(fā)送頻率限制沒配好用戶會抱怨收不到前端登錄類型沒開啟頁面上連郵箱登錄入口都沒有。所以配置 email 前最好先完整理解這套鏈路不然出問題了會像無頭蒼蠅一樣亂試。1.2 為什么郵件驗證碼比短信更適合某些場景我在多個項目里做過對比。短信驗證碼適合面向 C 端大眾用戶的移動端產(chǎn)品用戶手機號是天然的賬號體系但短信通道是要按條付費的而且國內(nèi)短信簽名、模板審核都比較麻煩個人開發(fā)者很難快速接入。郵件驗證碼的優(yōu)勢在于成本低、接入快。只要有一個能發(fā) SMTP 的郵箱個人開發(fā)者就能立刻用起來不需要申請簽名、不需要等審核而且郵件內(nèi)容可以做得更豐富附上品牌信息、用戶協(xié)議鏈接看起來比短信正式很多。缺點也很明顯郵件有延遲、可能進(jìn)垃圾箱、手機端查看不如短信方便。所以我的判斷是如果你的產(chǎn)品是開發(fā)者工具、SaaS 后臺、B 端服務(wù)或者做的是海外用戶email 登錄是首選如果是面向國內(nèi) C 端的娛樂類 App短信仍然更直接。uni-id-pages 的好處是兩種方式可以并存配置 email 不影響短信、微信等其他登錄方式這也是我選擇用它而不是自己寫用戶系統(tǒng)的原因。2. 先把郵件服務(wù)商和外發(fā)參數(shù)選好很多朋友一上來就直接在配置里填郵箱和密碼這是最常見的錯誤。uni-id-co 發(fā)郵件走的是 SMTP 協(xié)議你需要的是一個支持 SMTP 外發(fā)的郵箱或郵件服務(wù)而不是簡單的郵箱地址和登錄密碼。服務(wù)商選不對后面全是坑。2.1 各家 SMTP 服務(wù)對比我把常用的幾類郵件服務(wù)商放在一起對比過實際體驗差別很大服務(wù)商SMTP 地址端口獲取密鑰方式適合場景成本QQ 郵箱smtp.qq.com465/587開啟 SMTP 服務(wù)后生成授權(quán)碼個人項目、測試免費163 郵箱smtp.163.com465/994開啟 SMTP 后設(shè)置授權(quán)碼個人項目、測試免費阿里云郵件推送smtp.qiye.aliyun.com 等465/80控制臺配置發(fā)信域名正式業(yè)務(wù)、大量發(fā)送按量計費Resendsmtp.resend.com465/587API Key 或 SMTP 密碼海外用戶、開發(fā)者工具免費額度SendGridsmtp.sendgrid.net465/587API Key海外用戶、大量發(fā)送免費額度如果你是個人開發(fā)者、只是想快速把郵箱驗證碼跑通我用 QQ 郵箱或者 163 郵箱就夠了流程最短不涉及域名備案和 DNS 解析。但如果項目要上線、面向真實用戶我不建議用個人免費郵箱去發(fā)驗證碼會有幾個問題單日發(fā)信數(shù)量限制、郵件容易被判垃圾郵件、發(fā)信域名和產(chǎn)品域名不一致導(dǎo)致 SPF/DKIM 認(rèn)證過不了。這時候應(yīng)該用阿里云郵件推送或者 Resend 這類專門的服務(wù)配置發(fā)信域名和 DNS 記錄送達(dá)率會高很多。我這次項目里因為要對接國內(nèi)外用戶國內(nèi)環(huán)境我用的是 QQ 郵箱 SMTP 做快速驗證驗證通過后把發(fā)信能力切到了 Resend兩者在 uni-id-co 里的配置格式基本一致切換成本很低。2.2 授權(quán)碼不是密碼這步錯了全白搭QQ 郵箱和 163 郵箱的坑在同一個地方SMTP 認(rèn)證需要的不是你的郵箱登錄密碼而是“授權(quán)碼”。授權(quán)碼是你在郵箱設(shè)置里開啟 SMTP 服務(wù)后平臺生成的一串十六位左右的長字符串。如果你在 uni-id-co 的配置里填了登錄密碼SMTP 服務(wù)器會返回認(rèn)證失敗郵件絕對發(fā)不出去。以 QQ 郵箱為例獲取授權(quán)碼的路徑是網(wǎng)頁版 QQ 郵箱 → 設(shè)置 → 賬號與安全 → 安全設(shè)置 → 開啟 SMTP 服務(wù)開啟后會引導(dǎo)你發(fā)送一條短信驗證驗證通過后就會生成授權(quán)碼。這個授權(quán)碼只在開啟時看到一次建議立刻復(fù)制保存到自己的密碼管理器里。163 郵箱的路徑類似網(wǎng)頁版 163 郵箱 → 設(shè)置 → POP3/SMTP/IMAP → 開啟 SMTP 服務(wù) → 設(shè)置授權(quán)碼。需要注意授權(quán)碼和登錄密碼是兩回事即使你知道郵箱密碼沒有授權(quán)碼也無法走 SMTP。另外有些郵箱服務(wù)商在你異地登錄、更換設(shè)備后會重置授權(quán)碼如果你昨天配置還好的、今天突然發(fā)不出郵件先去檢查授權(quán)碼是否失效。3. 服務(wù)端 uni-id-co 的郵箱配置實操配置分兩層云對象 uni-id-co 的配置文件以及 uniCloud 環(huán)境變量/公共模塊的配置。這里我把關(guān)鍵操作一步步寫清楚。3.1 找到配置文件在 uniCloud 項目里uni-id-co 云對象的核心配置實際上在配套的 uni-id 公共模塊中。目錄結(jié)構(gòu)大致是這樣uniCloud-aliyun/cloudfunctions/ uni-id-co/ index.js config.json package.json common/ uni-id/ config.json --- 這里存放 uni-id 的配置 package.json如果你的項目是從插件市場直接導(dǎo)入 uni-id-pages 的通常會自動帶上 uni-id-co 云對象和 uni-id 公共模塊。如果還沒有需要在插件市場搜索并添加這兩個依賴執(zhí)行上傳部署后才能生效。我把 uni-id 公共模塊里的 config.json 視為整個用戶體系的核心配置郵件、短信、token 過期時間、密碼規(guī)則、驗證碼規(guī)則都在這里控制。3.2 核心配置項拆解我這次用的 uni-id 配置文件里郵件相關(guān)的部分如下{ email: { smtp: { host: smtp.qq.com, port: 465, secure: true, user: your_emailqq.com, pass: your_authorization_code }, sendCode: { scene: { login: { template: 您的登錄驗證碼為 ${code}請在 ${expiresIn} 分鐘內(nèi)填寫。 }, register: { template: 您的注冊驗證碼為 ${code}請在 ${expiresIn} 分鐘內(nèi)填寫。 }, reset-password: { template: 您正在重置密碼驗證碼為 ${code}請在 ${expiresIn} 分鐘內(nèi)填寫。 }, bind: { template: 您正在綁定郵箱驗證碼為 ${code}請在 ${expiresIn} 分鐘內(nèi)填寫。 }, unbind: { template: 您正在解綁郵箱驗證碼為 ${code}請在 ${expiresIn} 分鐘內(nèi)填寫。 } }, codeExpiresIn: 600, sendInterval: 60 } } }這里每個配置項都有意義smtp.host和smtp.port對應(yīng)你選擇的郵件服務(wù)商的 SMTP 地址和端口。QQ 郵箱是 smtp.qq.com:465Resend 是 smtp.resend.com:465。端口用 465 是 SSL 加密連接587 是 STARTTLS兩者都能用但 465 在 uni-id-co 里表現(xiàn)更穩(wěn)我在項目里用的就是 465。smtp.securetrue 表示使用 SSL 加密連接和 465 端口是一對。如果端口寫成 587建議 secure 用 false 或者看服務(wù)商要求。這個參數(shù)寫錯了會連接失敗報錯信息通常是 TLS 握手失敗。smtp.user和smtp.passuser 是完整郵箱地址pass 是授權(quán)碼/API Key。這里不是密碼再次強調(diào)。sendCode.scene不同業(yè)務(wù)場景下的郵件模板模板里的${code}和${expiresIn}會被 uni-id-co 自動替換成真實驗證碼和有效分鐘數(shù)。你可以調(diào)整文案以適應(yīng)產(chǎn)品的語氣。codeExpiresIn驗證碼有效期單位秒。我設(shè)的是 600也就是 10 分鐘。太短用戶來不及收郵件太長有安全風(fēng)險。sendInterval發(fā)送間隔單位秒。60 表示同一個郵箱 60 秒內(nèi)只能發(fā)一次驗證碼防止用戶手抖反復(fù)點擊、也防止接口被刷。3.3 部署與日志觀察配置文件改好后記住一件事一定要把 uni-id 公共模塊重新上傳部署到云服務(wù)空間uni-id-co 也要同步上傳否則配置不生效。這個坑我踩過本地改了配置但忘了在 HBuilderX 里右鍵上傳公共模塊結(jié)果線上還是舊配置白白排查了一晚上。部署完成后建議先在 HBuilderX 運行到瀏覽器打開 uni-id-pages 的登錄頁切換到郵箱驗證碼登錄輸入你的測試郵箱點擊發(fā)送驗證碼。這時候打開 uniCloud 控制臺的云函數(shù)日志搜索 uni-id-co 的調(diào)用記錄能看到 sendEmailCode 的執(zhí)行結(jié)果。如果配置正確返回碼是 0日志里會有一條類似 “發(fā)送郵件成功” 的記錄如果配置錯誤日志里會有返回碼 500 或者 SMTP 的錯誤信息。云函數(shù)日志是排查郵件問題的第一現(xiàn)場。很多問題在頁面上看不到細(xì)節(jié)但在日志里會直白地告訴你認(rèn)證失敗、連接超時還是端口不通。我每次配置完都會習(xí)慣性看一輪日志確認(rèn) SMTP 連接成功后才繼續(xù)往下走。4. 前端 uni-id-pages 開啟郵箱登錄入口服務(wù)端配好了前端的入口也得打開。uni-id-pages 默認(rèn)可能只顯示賬號密碼登錄需要手動把 email 登錄類型加進(jìn)去。4.1 登錄類型配置uni-id-pages 插件在項目里會有一個配置文件通常是uni-id-pages/config.js或uni-id-pages.config.js位置可能是頁面目錄下的 config.js也可能在項目的 config 目錄里。我這次項目里的配置大致長這樣// uni-id-pages/config.js export default { loginTypes: [email, password], // ... }loginTypes數(shù)組控制顯示哪些登錄方式可選項包括password、sms、email、univerify、apple等。把email加進(jìn)去后登錄頁就會出現(xiàn)郵箱驗證碼登錄的標(biāo)簽或圖標(biāo)。注意email登錄和password登錄是兩套邏輯前者只靠驗證碼登錄不需要用戶設(shè)置密碼后者是賬號密碼登錄。如果你的項目還需要用戶能在后臺綁定郵箱記得把郵箱驗證碼場景里的bind和unbind也配置上否則綁定郵箱功能會報“驗證碼場景不存在”一類的錯誤。4.2 頁面表單與驗證碼按鈕uni-id-pages 內(nèi)置的頁面已經(jīng)實現(xiàn)了郵箱輸入框和“獲取驗證碼”按鈕的邏輯不需要你重新寫。它會自動從配置里讀取郵箱場景點擊“獲取驗證碼”后調(diào) uni-id-co 的 sendEmailCode并按照sendInterval做倒計時。有一點要留意uni-id-pages 頁面上顯示的登錄方式優(yōu)先級和你loginTypes數(shù)組的順序一致。如果你把email放第一個默認(rèn)展示的就是郵箱登錄表單。我建議產(chǎn)品上如果主推郵箱就把 email 放最前密碼登錄放第二個這樣對新用戶更友好。如果項目不是直接用 uni-id-pages 的完整頁面而是自己寫的自定義登錄表單也可以直接掉云對象方法核心調(diào)用是這樣const uniIdCo uniCloud.importObject(uni-id-co) // 發(fā)送驗證碼 await uniIdCo.sendEmailCode({ email: userexample.com, scene: login }) // 郵箱驗證碼登錄 const res await uniIdCo.login({ email: userexample.com, code: 123456, scene: login })這個方法調(diào)用方式在任何自定義頁面上都可以用所以哪怕你不用 uni-id-pages 自帶的頁面只參考它的工程結(jié)構(gòu)也能自由擴展。5. 用 moakt 臨時郵箱把整套鏈路測通測試郵箱驗證碼最怕什么一收不到、二收不到還找不到原因。以前我測試時用的是自己的 QQ 郵箱問題是每次測試都要切到郵箱客戶端去收信驗證碼時效 10 分鐘來回折騰效率很低。這次我用了臨時郵箱工具 moakt整個過程順暢了很多。5.1 為什么要用臨時郵箱moaktmoakt.com是一個臨時郵箱服務(wù)打開網(wǎng)站會自動生成一個隨機郵箱地址比如abc123moakt.com你不需要注冊、不需要密碼頁面會實時顯示收到的郵件。這個地址可以直接當(dāng)測試收件郵箱使用。用它來測 uni-id-pages 的郵箱驗證碼有幾個好處一是即開即用輸入郵箱地址后直接就能在頁面上等郵件不用切換 App二是不需要自己真的有一個郵箱來收信尤其適合團隊里需要多人聯(lián)調(diào)時每個人都開一個臨時地址互不干擾三是臨時郵箱收到郵件后可以直接復(fù)制驗證碼效率高很多。注意moakt 這類臨時郵箱只適合開發(fā)測試千萬不能給真實用戶用。生產(chǎn)環(huán)境的用戶收信一定要用真正可長期訪問的郵箱服務(wù)否則驗證碼發(fā)出去用戶根本收不到賬號也登不進(jìn)去。5.2 本地測試的完整過程我在本地完整的測試流程是打開 moakt.com頁面會自動分配一個臨時郵箱地址我復(fù)制下來一般是xxxmoakt.com這種格式。在 HBuilderX 里運行 uni-app 項目到瀏覽器打開 uni-id-pages 登錄頁切換到“郵箱驗證碼登錄”把剛才的臨時郵箱粘貼進(jìn)去。點擊“獲取驗證碼”等 1-3 秒。正常情況下按鈕進(jìn)入倒計時表示請求已經(jīng)發(fā)出?；氐?moakt.com 頁面如果配置正確收件箱里很快會出現(xiàn)一封來自你配置發(fā)件郵箱的郵件主題一般是“驗證碼”或你自定義的主題。點開郵件能看到驗證碼數(shù)字。把驗證碼填回登錄表單點擊登錄正常情況下會跳回首頁uni-id 的用戶表里也會新增一條用戶記錄。我實際測試時QQ 郵箱的 SMTP 發(fā)到 moakt 的郵箱大概需要 2-5 秒偶爾會等十幾秒這是正常的。如果超過 1 分鐘還沒收到基本可以判斷是配置問題或者郵件被服務(wù)商攔截了直接去云函數(shù)日志里看有沒有報錯。測試完以后我建議把 moakt.com 這種臨時郵箱徹底從生產(chǎn)環(huán)境的代碼和文檔里清理掉不然哪天不小心把服務(wù)配置成發(fā)往臨時郵箱用戶驗證碼全部丟失那就是事故了。6. 高頻問題排查實錄配置過程里我踩了不少坑也幫朋友排查過類似問題把最容易被卡住的點整理成一個速查表按優(yōu)先級排列。6.1 收不到驗證碼這是遇到最多的場景現(xiàn)象是前端提示“發(fā)送成功”但郵箱里就是沒有郵件。這分兩種可能可能原因判斷方法解決辦法SMTP 認(rèn)證失敗云函數(shù)日志里有 SMTP 535 或 Authentication 錯誤檢查smtp.pass是否填了授權(quán)碼而不是登錄密碼郵件進(jìn)垃圾箱看垃圾郵件文件夾郵件內(nèi)容避免誘導(dǎo)性詞匯配置發(fā)信域名 SPF/DKIM服務(wù)商延遲等待 1 分鐘以上檢查發(fā)信日志部分服務(wù)商高峰期有延遲郵箱寫錯用戶在輸入框里多打了空格在業(yè)務(wù)層做郵箱格式和去空格處理如果是“發(fā)送成功”但收不到我建議第一時間看云函數(shù)日志確認(rèn) SMTP 是否真的連接成功。日志里顯示“發(fā)送郵件成功”但郵件沒到大概率是垃圾箱或者延遲日志里顯示錯誤就按錯誤信息去修。6.2 SMTP 連接失敗 / 端口不通連接失敗常見的報錯有connect ETIMEDOUT、socket hang up、TLS handshake failed。這類問題大多出在端口和加密方式上。QQ 郵箱的 465 端口在 uniCloud 阿里云環(huán)境里是可以通的但有些郵件服務(wù)商的 465 端口對境外服務(wù)器不一定開放。如果你用的是阿里云郵件推送建議直接按服務(wù)商文檔里的端口和加密方式配置不要照搬 QQ 郵箱的參數(shù)。ETIMEDOUT通常是網(wǎng)絡(luò)不通先確認(rèn)服務(wù)商的防火墻策略TLS handshake failed通常是secure參數(shù)不對465 對應(yīng) true,587 對應(yīng) false 或 STARTTLS 模式。把端口和 secure 的搭配關(guān)系對照一下就能解決大部分連接問題。6.3 驗證碼校驗報錯另外一種情況,驗證碼收到了,但登錄時報“驗證碼錯誤”或者“驗證碼已過期”。我排查下來常見原因有兩個。第一個原因是場景不一致。發(fā)送驗證碼時用的 scene 是register登錄時調(diào)用的 scene 是loginuni-id-co 對驗證碼是按郵箱場景時間戳組合校驗的場景對不上會直接判無效。前端頁面一般不會自己搞混但如果你在自定義表單里先后調(diào) sendEmailCode 和 login務(wù)必保證兩個 scene 一致。第二個原因是驗證碼有效期太短。codeExpiresIn如果設(shè)成 1202分鐘用戶還沒收到郵件驗證碼就過期了。建議至少設(shè) 300 秒我用 600 秒是比較從容的。還有一個小坑有些郵件服務(wù)商或者客戶端會解析郵件里的數(shù)字后被格式化用戶復(fù)制驗證碼時可能帶進(jìn)空格或換行。前端提交前最好做一次trim()或者校驗時忽略空白字符。我在自建表單時遇到過用戶從郵件里復(fù)制驗證碼多了個空格結(jié)果一直報錯去掉空格就成功了。6.4 郵件進(jìn)垃圾箱即使技術(shù)配置全對郵件進(jìn)垃圾箱也是可能發(fā)生的這直接決定用戶體驗。個人郵箱發(fā)驗證碼本來就很容易被判垃圾郵件因為你的發(fā)信 IP、域名信譽、郵件內(nèi)容都會影響算法的判斷。幾個改變送達(dá)率的有效做法一是郵件模板里不要出現(xiàn)“免費”“中獎”“點擊鏈接”這類高風(fēng)險的詞驗證碼郵件文案保持簡潔、正式二是發(fā)件人名稱和郵箱域名盡量和產(chǎn)品品牌一致不要整封郵件都是亂碼或者英文夾雜拼音三是在正式環(huán)境用專業(yè)郵件服務(wù)并配置 SPF、DKIM 記錄這會顯著提高送達(dá)率四是郵件里把用戶的完整郵箱寫進(jìn)正文例如“這封郵件發(fā)送給 userexample.com”很多垃圾郵件過濾規(guī)則會識別這種為正常郵件。我測試期間用 QQ 郵箱發(fā)到 moakt 臨時郵箱大多數(shù)情況能正常收到但偶爾也會進(jìn)垃圾箱這屬于測試鏈路可以接受的范圍內(nèi)。真要上線我會優(yōu)先用專業(yè)發(fā)送服務(wù)而不是糾結(jié)于免費郵箱的送達(dá)率。6.5 配置已改但頁面無變化還有一類問題不在郵件本身而是配置改了之后不起作用。現(xiàn)象是 uni-id-pages 登錄頁還是老樣子或者驗證碼發(fā)送行為沒有任何變化。這一般是緩存問題。uni-id-pages 是前端頁面插件部分配置會被編譯進(jìn)前端代碼需要重新運行項目才能生效云端的 uni-id-co 配置則必須重新上傳部署公共模塊。我每次改完配置都會做三個動作重新運行前端、重新上傳 uni-id-co、在云函數(shù)測試?yán)锸謩訄?zhí)行一次 sendEmailCode 驗證配置確保改動真正生效。如果項目里有自建的數(shù)據(jù)庫表結(jié)構(gòu)還要確認(rèn) uni-id 的用戶表已經(jīng)初始化過。新服務(wù)空間首次使用 uni-id-pages 時如果沒跑初始化腳本用戶表不存在登錄會報錯。這個表結(jié)構(gòu)初始化通常在 uniCloud 控制臺的云數(shù)據(jù)庫里通過執(zhí)行 uni-id 配套的 db_init.json 或遷移腳本來完成不同的項目版本初始化的方式略有區(qū)別但官方文檔和插件說明里都有照著做一遍就不容易出錯。7. 上線前我還想再說幾個細(xì)節(jié)這一路配置完、測試通過并不代表就完事了。有幾個細(xì)節(jié)我在多個項目里反復(fù)驗證過建議上線前一定過一遍驗證碼發(fā)送必須有頻率限制不能只依賴前端倒計時。sendInterval這個參數(shù)就是服務(wù)端的硬限制一定要保留默認(rèn)值不要為了測試方便改成 0否則接口很容易被腳本刷單日發(fā)信額度也會很快耗盡。郵件模板要支持多語言。uni-id-pages 面向的可能是海外用戶默認(rèn)中文模板在國際化場景里不夠用?？梢栽?uni-id 公共模塊里維護(hù)不同語言版本的模板或者在調(diào)用 sendEmailCode 時傳入語言參數(shù)讓云對象動態(tài)選擇模板。我這次項目的用戶以中文為主但我也預(yù)留了英文模板避免以后接入海外版本時又要大改。要關(guān)注發(fā)信失敗率的監(jiān)控。郵件的送達(dá)率不會永遠(yuǎn)是 100%尤其用免費郵箱服務(wù)時可能某天發(fā)信額度耗盡、服務(wù)商臨時限流用戶那邊就收不到驗證碼了。建議在云函數(shù)日志里建立一個簡單的告警比如發(fā)信失敗連續(xù)超過一定數(shù)量就提醒。uniCloud 的日志服務(wù)和告警功能可以做到這一點成本很低但對用戶體驗的提升很明顯。還要在代碼里處理好異常分支。比如驗證碼發(fā)送成功但用戶長時間沒收到郵件頁面應(yīng)該給出“沒收到重新發(fā)送”的按鈕同時提示檢查垃圾箱。不要只彈一個冷冰冰的“發(fā)送成功”提示就結(jié)束要給用戶操作空間。uni-id-pages 內(nèi)置頁面有些交互已經(jīng)處理了但自定義頁面就需要自己補。最后說一下我個人的實際體會。uni-id-pages 配置 email 的事單純從技術(shù)實現(xiàn)上難度不高它真正的價值在于讓你在很短的時間內(nèi)獲得一套完整的、有前后端和數(shù)據(jù)庫支撐的用戶郵箱驗證碼體系。相比從零手寫郵件發(fā)送、驗證碼存儲、用戶表設(shè)計用這套現(xiàn)成方案可以省下不少重復(fù)工作把精力集中在業(yè)務(wù)邏輯和用戶體驗上。但“省事”的前提是你得理解它的配置層次前端頁面開入口、服務(wù)端云對象管邏輯、公共模塊存配置。三層各改各的缺一層都會出問題。不要一上來就盲目改配置先搞清楚每一層分別管什么再動手排查問題時也會更快定位到環(huán)節(jié)。如果你正準(zhǔn)備在自己的 uni-app 項目里接入郵箱驗證碼照著這篇文章的步驟走一遍大概率能在一小時內(nèi)跑通?？ㄗ×司腿タ丛坪瘮?shù)日志日志不會說謊。祝順利。