1、問(wèn)題現(xiàn)象

打開(kāi)待辦報(bào)錯(cuò)：“Cannot read properties of undefined (reading 'appApproveSetDTOS')”

2、問(wèn)題復(fù)現(xiàn)

1. 首先，詢(xún)問(wèn)用戶(hù)操作路徑，以及查看用戶(hù)出現(xiàn)問(wèn)題的現(xiàn)象，在測(cè)試及線(xiàn)上嘗試復(fù)現(xiàn)出問(wèn)題；
2. 查看用戶(hù)報(bào)錯(cuò)的具體原因，后端接口未報(bào)錯(cuò)，但返回?cái)?shù)據(jù)有缺失；前端報(bào)錯(cuò)開(kāi)發(fā)無(wú)法定位原因；
3. 分析數(shù)據(jù)庫(kù)數(shù)據(jù)，發(fā)現(xiàn)發(fā)起兩條審批，但實(shí)際用戶(hù)收到3條待辦，且有一個(gè)表單提交，卻有兩條審批數(shù)據(jù)app_authorization_approve_v2 及兩條待辦，時(shí)間間隔3s左右。
4. 初步斷定，是因?yàn)槟承┰驅(qū)е绿峤粚徟鷷r(shí)重復(fù)引起，于是在弱網(wǎng)或快速點(diǎn)擊的情況下，多次操作復(fù)現(xiàn)此問(wèn)題，復(fù)現(xiàn)出來(lái)。

3、原因分析

（1）表單授權(quán)，第一步，配置授權(quán)人員，觸發(fā)接口appAuthorizeAndApproveConfig，在表app_authorization_v2生成一條數(shù)據(jù)

（2）第二步，提交審批生成approveid，并填充到上一步的數(shù)據(jù)中【提交審批時(shí)，攜帶的authorizationIds會(huì)去app_authorization_v2中找id符合authorizationIds的數(shù)據(jù)，然后更新approveId】；同時(shí)生成待辦數(shù)據(jù)發(fā)到審批人

（3）發(fā)現(xiàn)問(wèn)題，當(dāng)觸發(fā)多次提交審批時(shí)，會(huì)生成多個(gè)approveid，同時(shí)生成多條待辦數(shù)據(jù)，但第一步生成的數(shù)據(jù)只有一條，approveid一直更新，最后一個(gè)approveid覆蓋到這條數(shù)據(jù)中。

當(dāng)待辦中根據(jù)approveid查待辦詳情數(shù)據(jù)時(shí)，只有最后一個(gè)待辦才能查到，其他的都查不到，所以打開(kāi)待辦頁(yè)面空白報(bào)錯(cuò)。

原因：多次提交時(shí)，后提交的數(shù)據(jù)在app_authorization_v2表更新approveid值，所以先提交的數(shù)據(jù)的approveId已經(jīng)找不到對(duì)應(yīng)的數(shù)據(jù)

總結(jié)：解決點(diǎn)擊提交審批時(shí)多次提交的問(wèn)題就可以了，因?yàn)樘峤粚徟鷷r(shí)多次提交，導(dǎo)致前一條的數(shù)據(jù)的approveId查不到對(duì)應(yīng)數(shù)據(jù)

4、解決方案1前端控制

與前后端開(kāi)發(fā)溝通后，決定采用“前端防抖與Loading限制”，防止接口重復(fù)調(diào)用

一、防抖(Debounce)的作用

基本原理
防抖是一種延遲執(zhí)行技術(shù)，它會(huì)將多次連續(xù)調(diào)用合并為一次調(diào)用，只有在指定的時(shí)間間隔內(nèi)沒(méi)有新調(diào)用時(shí)才會(huì)真正執(zhí)行。

在防止接口重復(fù)調(diào)用中的作用：
（1）高頻操作合并：將短時(shí)間內(nèi)多次觸發(fā)的事件合并為一次執(zhí)行
（2）減少無(wú)效請(qǐng)求：例如搜索框輸入時(shí)，只在用戶(hù)停止輸入300ms后才發(fā)起請(qǐng)求，而不是每輸入一個(gè)字符就請(qǐng)求一次
（3）防止快速連續(xù)點(diǎn)擊：按鈕防抖可以避免用戶(hù)快速多次點(diǎn)擊導(dǎo)致的重復(fù)提交

適用場(chǎng)景：
搜索框?qū)崟r(shí)搜索建議
窗口resize事件處理
按鈕防重復(fù)點(diǎn)擊（需配合視覺(jué)反饋）

局限性：
不能完全阻止刻意快速操作
防抖期間用戶(hù)看不到任何反饋，可能誤以為操作未生效

二、Loading限制的作用

基本原理
通過(guò)加載狀態(tài)鎖定界面，在請(qǐng)求完成前阻止用戶(hù)繼續(xù)操作。

在防止接口重復(fù)調(diào)用中的作用：
1、視覺(jué)+邏輯雙重鎖定：
2、明確的用戶(hù)反饋：通過(guò)加載動(dòng)畫(huà)讓用戶(hù)明確知道操作已接受，正在處理中
3、完整的請(qǐng)求周期控制：從點(diǎn)擊到響應(yīng)返回全程鎖定，比單純防抖更可靠

適用場(chǎng)景：
表單提交
重要操作確認(rèn)（支付、刪除等）
需要明確反饋的異步操作

優(yōu)勢(shì)：
提供更好的用戶(hù)體驗(yàn)
能有效防止請(qǐng)求發(fā)出后的重復(fù)操作
實(shí)現(xiàn)簡(jiǎn)單直接

三、結(jié)合后的效果：

防抖處理短時(shí)間內(nèi)多次點(diǎn)擊
Loading狀態(tài)防止防抖期間的新操作
請(qǐng)求發(fā)出后Loading防止重復(fù)提交
提供清晰的用戶(hù)反饋

四、對(duì)比總結(jié)

對(duì)于關(guān)鍵業(yè)務(wù)接口，建議同時(shí)使用兩種方案：防抖處理初始階段的快速操作，Loading確保請(qǐng)求過(guò)程中的狀態(tài)控制

image.png

5、解決方案2后端控制

邏輯控制

因?yàn)閷徟械臄?shù)據(jù)只有一條，故控制待辦也只能產(chǎn)生一條，這樣就不會(huì)有查不到approveId的情況了。

這種方案可從根本原因中控制住數(shù)據(jù)出錯(cuò)。

6、實(shí)際效果

經(jīng)過(guò)團(tuán)隊(duì)討論，前端進(jìn)行了控制即可，測(cè)試進(jìn)行了快速點(diǎn)擊、弱網(wǎng)操作、以及調(diào)用接口并發(fā)等方式進(jìn)行了驗(yàn)證，重復(fù)調(diào)用的情況確實(shí)得到了比較好的控制。

由于測(cè)試跟蹤需求及線(xiàn)上問(wèn)題比較多，考慮到此塊功能，多次出現(xiàn)問(wèn)題，之前在多處也進(jìn)行了loading限制，但問(wèn)題未根本解決。
此次防抖限制，是否能徹底解決問(wèn)題？

實(shí)際情況也是，測(cè)試環(huán)境未出現(xiàn)異常待辦，但線(xiàn)上測(cè)試賬號(hào)仍出現(xiàn)了。

既然知道后端邏輯可控制，為何不加雙重保險(xiǎn)？

最終決定，前端兩端都做改進(jìn)，最終觀察一段時(shí)間，發(fā)現(xiàn)問(wèn)題得以徹底解決。