1. 從改個(gè)密碼說(shuō)起為什么這個(gè)頁(yè)面比想象中難做修改密碼這四個(gè)字放在任何后臺(tái)系統(tǒng)里都像是最不起眼的一個(gè)功能。產(chǎn)品經(jīng)理畫(huà)原型的時(shí)候可能只給了一個(gè)彈窗前端拿到需求的第一反應(yīng)往往是半小時(shí)搞定。但真做過(guò)幾個(gè)中后臺(tái)項(xiàng)目的人都知道這個(gè)頁(yè)面是典型的看著簡(jiǎn)單、坑全在細(xì)節(jié)里——它同時(shí)牽扯到表單校驗(yàn)、接口安全、全局異常處理、加載態(tài)管理、路由守衛(wèi)這幾條線(xiàn)任何一條沒(méi)處理好用戶(hù)就會(huì)遇到點(diǎn)了沒(méi)反應(yīng)報(bào)錯(cuò)看不懂改完密碼還能用舊密碼登錄這類(lèi)問(wèn)題。這篇內(nèi)容圍繞一個(gè)基于 Element UI 的修改密碼頁(yè)面展開(kāi)核心要解決三件事頁(yè)面本身怎么設(shè)計(jì)才既安全又好用、加載態(tài)怎么管理才不閃爍不卡頓、異常怎么全局捕捉才能讓用戶(hù)看到人話(huà)而不是一串堆棧。適合正在做中后臺(tái)系統(tǒng)的前端開(kāi)發(fā)者尤其是用 Vue 2 Element UI 這套經(jīng)典組合的團(tuán)隊(duì)。哪怕你現(xiàn)在用的是 Vue 3 Element Plus思路也是通的只是 API 名字換一換。我先把結(jié)論擺前面修改密碼這個(gè)功能前端能做的安全防護(hù)其實(shí)很有限但體驗(yàn)優(yōu)化和異常兜底的空間非常大。很多人把精力全花在密碼強(qiáng)度正則上卻忽略了加載態(tài)和異常處理結(jié)果就是用戶(hù)改密碼改得一肚子火。下面我按實(shí)際開(kāi)發(fā)順序把每個(gè)環(huán)節(jié)拆開(kāi)講。2. 修改密碼頁(yè)面的字段設(shè)計(jì)與校驗(yàn)邏輯2.1 三個(gè)輸入框背后的真實(shí)需求一個(gè)標(biāo)準(zhǔn)的修改密碼表單通常是三個(gè)字段原密碼、新密碼、確認(rèn)新密碼?？雌饋?lái)平平無(wú)奇但每個(gè)字段的設(shè)計(jì)都有講究。原密碼字段的作用不只是驗(yàn)證身份它還有一個(gè)隱藏價(jià)值防止用戶(hù)在公共設(shè)備上被他人惡意改密。所以這個(gè)字段必須要求輸入且不能做任何記住上次輸入的處理autocomplete屬性要顯式設(shè)置為off或者new-password避免瀏覽器自動(dòng)填充把舊密碼暴露出來(lái)。新密碼字段是校驗(yàn)的重災(zāi)區(qū)。常見(jiàn)的強(qiáng)度規(guī)則包括長(zhǎng)度 8-20 位、必須包含大小寫(xiě)字母和數(shù)字、不能包含連續(xù)字符如 123456、abcdef、不能和原密碼相同。這里有個(gè)經(jīng)驗(yàn)規(guī)則不要一次性全堆給用戶(hù)看而是在輸入過(guò)程中動(dòng)態(tài)提示。Element UI 的el-form配合自定義validator就能做到用戶(hù)每輸入一個(gè)字符就實(shí)時(shí)反饋哪條規(guī)則還沒(méi)滿(mǎn)足比提交后彈一堆紅字友好得多。確認(rèn)密碼字段的核心是一致性校驗(yàn)但要注意一個(gè)細(xì)節(jié)當(dāng)用戶(hù)修改新密碼后確認(rèn)密碼的校驗(yàn)狀態(tài)需要重新觸發(fā)。很多人只寫(xiě)了validator卻忘了在newPassword變化時(shí)手動(dòng)validateField(confirmPassword)導(dǎo)致用戶(hù)改了新密碼、確認(rèn)框還顯示通過(guò)提交時(shí)才報(bào)錯(cuò)。2.2 用自定義 validator 把校驗(yàn)寫(xiě)扎實(shí)Element UI 的el-form校驗(yàn)依賴(lài)async-validator內(nèi)置規(guī)則能覆蓋大部分場(chǎng)景但密碼強(qiáng)度這種復(fù)合規(guī)則必須自己寫(xiě)。下面是一段我實(shí)際項(xiàng)目里用過(guò)的校驗(yàn)邏輯做了簡(jiǎn)化data() { const validateNewPassword (rule, value, callback) { if (!value) { return callback(new Error(請(qǐng)輸入新密碼)) } if (value this.form.oldPassword) { return callback(new Error(新密碼不能與原密碼相同)) } const hasLetter /[a-zA-Z]/.test(value) const hasNumber /\d/.test(value) if (!hasLetter || !hasNumber) { return callback(new Error(密碼需同時(shí)包含字母和數(shù)字)) } if (/(.)\1{2,}/.test(value)) { return callback(new Error(密碼不能包含三個(gè)及以上連續(xù)相同字符)) } callback() } const validateConfirm (rule, value, callback) { if (value ! this.form.newPassword) { return callback(new Error(兩次輸入的密碼不一致)) } callback() } return { form: { oldPassword: , newPassword: , confirmPassword: }, rules: { oldPassword: [{ required: true, message: 請(qǐng)輸入原密碼, trigger: blur }], newPassword: [{ required: true, validator: validateNewPassword, trigger: blur }], confirmPassword: [{ required: true, validator: validateConfirm, trigger: blur }] } } }這里有個(gè)容易忽略的點(diǎn)trigger用blur還是change。密碼強(qiáng)度校驗(yàn)建議用blur因?yàn)橛脩?hù)輸入過(guò)程中頻繁觸發(fā)校驗(yàn)會(huì)讓界面一直閃紅字體驗(yàn)很差而確認(rèn)密碼的一致性校驗(yàn)可以用change讓用戶(hù)改完立刻知道對(duì)不對(duì)。同一個(gè)表單里不同字段用不同 trigger是提升體驗(yàn)的細(xì)節(jié)。2.3 密碼可見(jiàn)性切換與輸入框的交互細(xì)節(jié)Element UI 的el-input支持show-password屬性一行代碼就能加上小眼睛切換。但要注意show-password在舊版本里叫show-password新版本 Element Plus 里也是這個(gè)名字別寫(xiě)成showPassword或者password否則不生效。另外三個(gè)密碼框建議都加上maxlength20防止用戶(hù)粘貼超長(zhǎng)字符串導(dǎo)致后端截?cái)嗷驁?bào)錯(cuò)。clearable屬性看情況加原密碼框不建議加避免用戶(hù)誤點(diǎn)清空后還得重新輸。3. 加載態(tài)管理別讓用戶(hù)對(duì)著白屏發(fā)呆3.1 頁(yè)面級(jí)加載與按鈕級(jí)加載的區(qū)別加載頁(yè)面這個(gè)需求很多人第一反應(yīng)是加個(gè)v-loading就完事了。但實(shí)際場(chǎng)景里加載態(tài)分兩個(gè)層級(jí)頁(yè)面級(jí)加載進(jìn)入修改密碼頁(yè)面時(shí)可能需要先拉取一些初始化數(shù)據(jù)比如用戶(hù)的安全問(wèn)題、密碼最后修改時(shí)間。這時(shí)候用v-loading蓋住整個(gè)表單區(qū)域是合理的。按鈕級(jí)加載用戶(hù)點(diǎn)擊確認(rèn)修改后請(qǐng)求發(fā)出到返回的這段時(shí)間應(yīng)該只讓提交按鈕進(jìn)入loading狀態(tài)而不是整個(gè)頁(yè)面轉(zhuǎn)圈。因?yàn)檎麄€(gè)頁(yè)面轉(zhuǎn)圈會(huì)讓用戶(hù)覺(jué)得系統(tǒng)卡死了而按鈕轉(zhuǎn)圈傳達(dá)的是正在處理你的請(qǐng)求心理感受完全不同。Element UI 的el-button自帶loading屬性直接綁定一個(gè)布爾值即可el-button typeprimary :loadingsubmitting clickhandleSubmit {{ submitting ? 提交中... : 確認(rèn)修改 }} /el-button注意loading狀態(tài)下按鈕會(huì)自動(dòng)禁用點(diǎn)擊不需要額外寫(xiě):disabled否則可能出現(xiàn)樣式?jīng)_突。3.2 防止重復(fù)提交的三重保險(xiǎn)加載態(tài)最核心的作用其實(shí)是防止重復(fù)提交。用戶(hù)網(wǎng)絡(luò)慢的時(shí)候會(huì)瘋狂點(diǎn)按鈕如果不做處理可能發(fā)出五六個(gè)請(qǐng)求后端如果沒(méi)做冪等密碼就被改了多次甚至出現(xiàn)新密碼是第幾次提交的這種詭異問(wèn)題。我的做法是三重保險(xiǎn)按鈕 loading視覺(jué)上禁用這是第一層。方法入口攔截在handleSubmit開(kāi)頭判斷if (this.submitting) return這是第二層防止鍵盤(pán)回車(chē)等繞過(guò)按鈕的操作。請(qǐng)求取消用 axios 的CancelToken或者 AbortController在組件銷(xiāo)毀或新請(qǐng)求發(fā)起時(shí)取消上一個(gè)未完成的請(qǐng)求這是第三層。第三層很多人不做但在用戶(hù)快速切換頁(yè)面時(shí)特別有用。如果不取消請(qǐng)求返回后組件已經(jīng)銷(xiāo)毀回調(diào)里訪(fǎng)問(wèn)this可能報(bào)錯(cuò)或者觸發(fā)一些莫名其妙的全局提示。3.3 加載態(tài)的最小展示時(shí)間有個(gè)反直覺(jué)的經(jīng)驗(yàn)加載態(tài)不要一閃而過(guò)。如果接口響應(yīng)特別快比如內(nèi)網(wǎng) 50ms 就返回loading 圖標(biāo)閃一下反而讓用戶(hù)覺(jué)得是不是沒(méi)點(diǎn)上。我一般會(huì)做一個(gè)最小展示時(shí)間比如 300ms用Promise.all配合一個(gè)延時(shí) Promise 實(shí)現(xiàn)const minDelay new Promise(resolve setTimeout(resolve, 300)) const request axios.post(/api/change-password, this.form) await Promise.all([request, minDelay])這樣無(wú)論接口多快loading 至少顯示 300ms視覺(jué)上更穩(wěn)定。當(dāng)然這個(gè)值別設(shè)太大超過(guò) 500ms 用戶(hù)就會(huì)覺(jué)得慢了。4. 全局異常捕捉讓報(bào)錯(cuò)說(shuō)人話(huà)4.1 為什么需要全局異常處理修改密碼接口可能返回各種錯(cuò)誤原密碼錯(cuò)誤、新密碼不符合后端規(guī)則、賬號(hào)被鎖定、token 過(guò)期、服務(wù)器 500。如果每個(gè)錯(cuò)誤都在catch里寫(xiě)一遍this.$message.error(err.message)代碼會(huì)又臭又長(zhǎng)而且不同開(kāi)發(fā)者寫(xiě)的提示風(fēng)格不統(tǒng)一有的顯示請(qǐng)求失敗有的顯示Error: Request failed with status code 400用戶(hù)看了完全懵。全局異常捕捉的價(jià)值就在于統(tǒng)一攔截、統(tǒng)一轉(zhuǎn)換、統(tǒng)一展示。前端拿到錯(cuò)誤后先判斷錯(cuò)誤類(lèi)型再?zèng)Q定是彈全局提示、跳登錄頁(yè)還是交給業(yè)務(wù)代碼自己處理。4.2 axios 攔截器里的錯(cuò)誤分類(lèi)處理我一般會(huì)在 axios 的響應(yīng)攔截器里做第一層處理按 HTTP 狀態(tài)碼和業(yè)務(wù)碼分類(lèi)axios.interceptors.response.use( response { const res response.data if (res.code ! 0) { // 業(yè)務(wù)錯(cuò)誤交給全局提示 handleBusinessError(res) return Promise.reject(res) } return res }, error { if (error.response) { const status error.response.status if (status 401) { // token 失效跳登錄 store.dispatch(user/logout) router.push(/login) Message.error(登錄已過(guò)期請(qǐng)重新登錄) } else if (status 403) { Message.error(沒(méi)有權(quán)限執(zhí)行此操作) } else if (status 500) { Message.error(服務(wù)器開(kāi)小差了請(qǐng)稍后重試) } else { Message.error(error.response.data.message || 請(qǐng)求失敗) } } else if (error.code ECONNABORTED) { Message.error(請(qǐng)求超時(shí)請(qǐng)檢查網(wǎng)絡(luò)) } else { Message.error(網(wǎng)絡(luò)異常請(qǐng)稍后重試) } return Promise.reject(error) } )這里的關(guān)鍵是區(qū)分能自動(dòng)處理的錯(cuò)誤和需要業(yè)務(wù)代碼處理的錯(cuò)誤。比如 401 直接跳登錄業(yè)務(wù)代碼不用管但原密碼錯(cuò)誤這種業(yè)務(wù)錯(cuò)誤可能需要把焦點(diǎn)定位到原密碼輸入框這就得讓業(yè)務(wù)代碼自己處理。所以攔截器里處理完通用錯(cuò)誤后仍然要reject讓業(yè)務(wù)層的catch有機(jī)會(huì)介入。4.3 業(yè)務(wù)錯(cuò)誤的提示策略修改密碼接口最常見(jiàn)的業(yè)務(wù)錯(cuò)誤就是原密碼錯(cuò)誤。這個(gè)提示不能只彈一個(gè) toast因?yàn)橛脩?hù)很可能需要重新輸入。我的做法是toast 提示 清空原密碼框 聚焦。async handleSubmit() { if (this.submitting) return try { await this.$refs.form.validate() } catch (e) { return } this.submitting true try { await changePassword(this.form) this.$message.success(密碼修改成功請(qǐng)重新登錄) setTimeout(() { this.$router.push(/login) }, 1000) } catch (err) { if (err.code OLD_PASSWORD_WRONG) { this.form.oldPassword this.$refs.oldPasswordInput.focus() } } finally { this.submitting false } }注意finally里一定要把submitting置回 false否則一旦出錯(cuò)按鈕就永遠(yuǎn)轉(zhuǎn)圈了。這是新手最容易犯的錯(cuò)誤之一。4.4 Vue 全局錯(cuò)誤捕獲兜底除了接口錯(cuò)誤還有一類(lèi)錯(cuò)誤是代碼運(yùn)行時(shí)錯(cuò)誤比如某個(gè)組件里訪(fǎng)問(wèn)了 undefined 的屬性。這類(lèi)錯(cuò)誤如果不捕獲整個(gè)頁(yè)面可能白屏。Vue 提供了Vue.config.errorHandler做全局兜底Vue.config.errorHandler function (err, vm, info) { console.error(全局捕獲:, err, info) // 上報(bào)到監(jiān)控平臺(tái) reportError(err, info) // 給用戶(hù)一個(gè)友好提示避免白屏 Message.error(頁(yè)面出現(xiàn)異常請(qǐng)刷新重試) }這個(gè)兜底不是萬(wàn)能的它捕獲不了 Promise 里未 catch 的錯(cuò)誤所以還需要監(jiān)聽(tīng)unhandledrejectionwindow.addEventListener(unhandledrejection, event { console.error(未處理的 Promise 錯(cuò)誤:, event.reason) reportError(event.reason) })兩層加起來(lái)基本能覆蓋絕大多數(shù)異常場(chǎng)景。5. 接口安全與前端能做的防護(hù)邊界5.1 前端加密到底有沒(méi)有用很多項(xiàng)目要求密碼傳輸前加密常見(jiàn)做法是用 RSA 或 AES 在前端加密后再發(fā)給后端。這里必須說(shuō)清楚前端加密不能替代 HTTPS。如果沒(méi)上 HTTPS中間人可以直接抓包拿到加密后的密文雖然不能直接還原明文但可以重放攻擊。前端加密的真正價(jià)值是防止日志和監(jiān)控系統(tǒng)記錄明文密碼。很多公司的接口日志會(huì)把請(qǐng)求體打出來(lái)如果不加密運(yùn)維和開(kāi)發(fā)就能在日志里看到用戶(hù)密碼這是合規(guī)大忌。所以前端加密更多是防內(nèi)部泄露而不是防外部攻擊。如果要做推薦用 RSA 公鑰加密公鑰由后端下發(fā)私鑰只在后端保存。前端用jsencrypt這類(lèi)庫(kù)即可但要注意公鑰的獲取時(shí)機(jī)和緩存策略別每次請(qǐng)求都去拉公鑰。5.2 修改成功后的強(qiáng)制下線(xiàn)密碼修改成功后必須讓當(dāng)前 token 失效并強(qiáng)制重新登錄。原因很簡(jiǎn)單如果舊 token 還能用那攻擊者拿到舊 token 依然能操作改密碼就失去了意義。實(shí)現(xiàn)上有兩種方式一是后端在改密成功后主動(dòng)使該用戶(hù)所有 token 失效前端收到成功響應(yīng)后跳登錄頁(yè)二是前端在成功后主動(dòng)調(diào)登出接口。推薦第一種因?yàn)楦踩岸酥恍枰?fù)責(zé)跳轉(zhuǎn)。跳轉(zhuǎn)前給用戶(hù)一個(gè)明確的提示比如密碼修改成功即將重新登錄然后延遲 1-2 秒跳轉(zhuǎn)讓用戶(hù)有時(shí)間看到提示。直接瞬間跳轉(zhuǎn)會(huì)讓用戶(hù)困惑我剛才到底改成功沒(méi)有。5.3 密碼字段的自動(dòng)填充與瀏覽器記憶瀏覽器對(duì)typepassword的輸入框有自動(dòng)填充和記住密碼的行為這在修改密碼場(chǎng)景里是負(fù)面的。除了設(shè)置autocompletenew-password還可以用一些技巧把原密碼框的name屬性設(shè)成一個(gè)不常見(jiàn)的值避免瀏覽器識(shí)別為登錄表單。在表單外層包一個(gè)autocompleteoff的 form。如果還是被填充可以在mounted里延遲清空一次。這些手段不能 100% 阻止瀏覽器行為但能大幅降低誤填充概率。6. 踩坑實(shí)錄那些文檔里不會(huì)寫(xiě)的細(xì)節(jié)6.1 el-form 校驗(yàn)的異步陷阱this.$refs.form.validate()返回的是一個(gè) Promise但如果你傳了回調(diào)函數(shù)它就不返回 Promise 了。很多人混用兩種寫(xiě)法導(dǎo)致await拿不到結(jié)果// 錯(cuò)誤寫(xiě)法傳了回調(diào)await 拿到的是 undefined await this.$refs.form.validate((valid) { ... }) // 正確寫(xiě)法一不傳回調(diào)用 try/catch try { await this.$refs.form.validate() } catch (e) { return } // 正確寫(xiě)法二傳回調(diào)不用 await this.$refs.form.validate((valid) { if (valid) { this.submit() } })這個(gè)坑我見(jiàn)過(guò)至少五個(gè)同事踩過(guò)表現(xiàn)就是校驗(yàn)沒(méi)通過(guò)但請(qǐng)求還是發(fā)出去了。6.2 loading 與路由跳轉(zhuǎn)的時(shí)序問(wèn)題改密成功后跳登錄頁(yè)如果跳轉(zhuǎn)太快loading 狀態(tài)還沒(méi)重置登錄頁(yè)可能繼承一些奇怪的全局狀態(tài)。我的做法是先重置 loading再跳轉(zhuǎn)并且用setTimeout給一個(gè)緩沖this.submitting false this.$message.success(修改成功) setTimeout(() this.$router.push(/login), 800)另外如果用了 keep-alive 緩存了這個(gè)頁(yè)面跳轉(zhuǎn)前記得把表單重置否則用戶(hù)下次進(jìn)來(lái)還看到上次的密碼雖然密碼框顯示的是圓點(diǎn)但值還在。6.3 全局異常處理與業(yè)務(wù)提示的沖突有時(shí)候全局?jǐn)r截器已經(jīng)彈了一個(gè)錯(cuò)誤提示業(yè)務(wù)代碼的catch里又彈了一個(gè)用戶(hù)就看到兩個(gè) toast 疊在一起。解決辦法是在錯(cuò)誤對(duì)象上打標(biāo)記// 攔截器里 error.handled true Message.error(...) // 業(yè)務(wù)層 catch (err) { if (!err.handled) { Message.error(err.message) } }這樣全局處理過(guò)的錯(cuò)誤業(yè)務(wù)層就不再重復(fù)提示。這個(gè)模式在大型項(xiàng)目里幾乎是標(biāo)配。6.4 密碼強(qiáng)度提示的實(shí)時(shí)性前面提到用blur觸發(fā)校驗(yàn)但強(qiáng)度提示比如還需包含數(shù)字最好用input事件實(shí)時(shí)更新而不是等失焦。可以單獨(dú)維護(hù)一個(gè)strengthTips數(shù)組在input時(shí)計(jì)算computed: { strengthTips() { const pwd this.form.newPassword return [ { text: 至少8位, ok: pwd.length 8 }, { text: 包含字母, ok: /[a-zA-Z]/.test(pwd) }, { text: 包含數(shù)字, ok: /\d/.test(pwd) } ] } }然后在模板里用不同顏色渲染用戶(hù)輸入時(shí)就能看到哪條變綠了體驗(yàn)比提交后報(bào)錯(cuò)好太多。7. 一套可復(fù)用的實(shí)現(xiàn)骨架把上面的內(nèi)容串起來(lái)一個(gè)完整的修改密碼頁(yè)面大致包含這些部分表單結(jié)構(gòu)、校驗(yàn)規(guī)則、加載態(tài)管理、提交邏輯、異常處理、成功后的跳轉(zhuǎn)。我把它整理成一個(gè)對(duì)照表方便你按圖索驥模塊關(guān)鍵點(diǎn)常見(jiàn)坑表單字段原密碼、新密碼、確認(rèn)密碼忘記關(guān)閉自動(dòng)填充校驗(yàn)規(guī)則自定義 validator、動(dòng)態(tài) trigger改新密碼后未重校驗(yàn)確認(rèn)框加載態(tài)按鈕級(jí) loading、最小展示時(shí)間出錯(cuò)后未重置 loading防重復(fù)提交入口攔截 請(qǐng)求取消只靠按鈕禁用回車(chē)可繞過(guò)全局異常攔截器分類(lèi)處理、錯(cuò)誤標(biāo)記全局與業(yè)務(wù)重復(fù)彈提示成功后處理強(qiáng)制下線(xiàn)、延遲跳轉(zhuǎn)跳轉(zhuǎn)過(guò)快、狀態(tài)未重置這套骨架我在幾個(gè)中后臺(tái)項(xiàng)目里反復(fù)用過(guò)基本能覆蓋 90% 的修改密碼場(chǎng)景。剩下的 10% 是各家的特殊需求比如有的要求改密后發(fā)郵件通知有的要求二次驗(yàn)證那些就在這個(gè)骨架上加鉤子即可。最后分享一個(gè)我自己的習(xí)慣修改密碼頁(yè)面寫(xiě)完一定要用慢網(wǎng)絡(luò)模擬測(cè)一遍。Chrome DevTools 里把網(wǎng)絡(luò)調(diào)到 Slow 3G然后瘋狂點(diǎn)提交按鈕看看會(huì)不會(huì)重復(fù)請(qǐng)求、loading 會(huì)不會(huì)卡死、錯(cuò)誤提示會(huì)不會(huì)疊。這個(gè)測(cè)試花不了五分鐘但能提前發(fā)現(xiàn)大部分加載態(tài)和異常處理的問(wèn)題。比等到測(cè)試同學(xué)提 bug 再改成本低得多。