我的建議，究竟有誰會看，以我的位置，到底能推動到哪一層
可行性，可能性

問題：
使用者的資料丟失了。以為是修改操作 有bug，但查看了後端介面和前端校驗，都沒有發現問題。
但是input資料沒有日誌【日誌級別是debug】，不能自證清白。
並且一些沒有辦法輕易證明的猜測也有：是不是併發問題，一個insert操作操作剛完成，另一個請求上來了，把這個新insert的資料刪除了。查了api閘道器，真找到有兩個觸發時間比較接近的兩個請求 。。。
糾結中：這個簡單的邏輯，還出問題，覺得很不爽，也不服氣。

tips:這種情況下，可以使用這種話術----”我先看一下“   如果直接說”這麼介面這麼簡單，怎麼可能有問題“ ---------------提出bug的人，可能覺得自己提出的判斷或事實，被否定了。
            


解決辦法：
是修改介面被誤用，在別的場景中被呼叫了

背景： 需求描述

有一個 一個頁面新增多個項的操作，
並且支援對多個項 進行 修改， 刪除幾個原有的，再新增幾個

方案1：對已有id的更新，對沒有id的進行insert ，還有對 刪除項 進行刪除-----這個貌似是最好的。略有複雜
刪除，如果使用邏輯刪除，則在 新增的記錄 時，要不要和已有刪除項的資料進行對比呢，如果已存在，則更新老的標識位，讓其可見即可------ 問題：怎麼判定是一條相同的記錄呢。特別是欄位比較多的場景

方案1：先刪再增
是邏輯刪，還是物理刪除。

可以邏輯刪，但要定時清表。對於操作頻繁的表，資料量會越來越多

問題：
一個介面有變更，但介面沒有按 單一職責 進行設計，呼叫散落在了不同的業務點。 
思考--對一個表不同欄位的修改，可能會用於不同的場景。 看到有不少地方是到處使用這個介面，這就造成 引數校驗會散落在各個場景
一個對錶的修改操作