1、異步處理時防止重復點擊的邏輯校驗
場景 打款請求時，進入異步處理的隊列，生成一個任務號，存在如數據庫，且狀態為未完成。此時，如果並發操作，如重復點擊或者重復調用接口，則發出的兩條請求可能被分配到不同服務器處理，此時數據庫產生兩條數據，同一任務id對應不同進程id，屬於異常場景。程序邏輯判斷數據>2，不處理，則異步任務終止。
其中，重復點擊導致產生兩條數據的原因僅為猜測，實際排查過程中發現，前端已經做了防重復點擊，可能是后端的前置邏輯導致對同一批數據做兩次請求
總結 不僅在同步業務處理時需要注意並發問題，異步任務時也需要根據實現邏輯關注中間狀態
解決 1、數據庫加聯合唯一索引，第二條數據寫不進去，直接將數據庫報錯拋出
2、忽略兩天數據的場景，當做正常業務處理，兩條都進行更新
3、 排查產生兩條數據的原因，源頭上杜絕
最終方案選擇了2 當時我選擇的是1和3,1作為立即解決的方案，在不動業務邏輯的場景下，解決問題，風險較小。3作為后續的溯源很有必要。但是最后沒爭過開發
2、臨時小需求對系統功能的影響，需要思考后再做回歸
eg.列表新增字段的需求，需要新增一個時間標簽。當做一個簡單的回歸時正常。但是這個列表中有三個寫入的業務類型，其中一個寫入類型與其他寫入的函數不同。此時，由於未對第三個業務類型進行回歸，導致漏測。這也是為什么測試需要參與設計評審的原因。
分析：正常的業務場景和實現方式來說，基於復用原則，和通用的代碼實現方式，這種寫入應該都是在同一個函數完成。但是防不勝防啊。需求急測試不能急，任何小的修改都可能對你之前的測試結果形成覆蓋
3、客戶端測試時，需要注意系統與原生兼容和交互，如獲取權限，打開文件等
4、前后端交互問題，前端頁面展示錯誤、請求參數錯誤、交互錯誤這種類型的bug咱就不提了。主要說一種，請求的同步和異步，也就是時間對請求結果的影響，和前端在處理請求結果時，是否會基於時間的考慮來展示返回結果。
先來個簡單的例子，在某修改功能中，要求前端請求后進行查詢，以便在列表展示上獲取剛才的修改提交。此時，先發出修改請求，再發出查詢請求，如果修改請求仍在處理，還沒有成功，便返回查詢結果，然后返回修改結果，修改成功。此時就造成了展示內容與實際結果不一致。所以查詢接口應該等待修改接口返回結果后再發出
前后端交互中也存在同步異步問題。同步就是上面的例子。下面是前后端交互的兩種異步場景。
a、輪詢（polling） 間隔一定時間不斷向后端發送請求，如導出功能，第一次請求導出時，后端給到一個任務id，然后前端拿着這個id每隔1秒請求一次。確定就是消耗大，有延遲。延遲問題可以通過長輪詢方式解決，具體自行擴展
b、websocket是跟http一樣性質的傳輸協議。詳細區別自己找找，這里就談一個，http是單向的，websocket是雙向的協議。所以很明了，websocket 協議中，服務器端會主動向瀏覽器端發送結果，進而可以降低延遲。缺點就是資源消耗大。所以在生命周期結束時，應該關閉連接