幽默輕鬆小知識，一起來看看老弟第一次寫的後端程式碼，你覺得如何？
大家好，我是魚皮，今天分享我的老弟第一次寫後端程式碼時出現的囧事，希望大家引以為戒。
孽起
我的老弟小阿巴，目前大一，自學程式設計有一段時間了，之前主要以學前端為主，比較好上手。
但這貨最近不知道咋回事，一直嚷嚷著要寫寫後端程式碼。
我說：你前端才剛學沒多久呢，急什麼？
小阿巴說：沒人比我更懂前端！
好傢伙，沒想到幾日不見，這傢伙現在這麼驕傲了！那必須得殺殺他的銳氣，讓他領略一下後端的恐怖。
於是我說：成，正好我最近在開發一個新功能【刪除訊息】，功能很簡單，允許使用者刪除自己已經閱讀過的訊息。前端後端都交給你來做，時間也不急，給你兩週，拿去練練手，熟悉下專案吧~
沒想到小阿巴這狗說：兩週？瞧不起誰呢，就這麼一個小功能，我 3 天給你搞定！
我大驚：現在的年輕人都這麼強了麼？行，我等你！
沒想到，不到 3 天，小阿巴真的提交了程式碼，讓我們一起來看看他的實現思路和程式碼吧。
實現思路
功能實現包括前端和後端兩部分，分別來思考一下。
前端
要實現使用者已讀訊息刪除功能，前端的工作比較簡單，新增一個刪除按鈕，並且給按鈕新增一個點選事件，點選後呼叫後端
訊息刪除
介面即可。
前端介面
小阿巴寫的前端程式碼：
<！—— 虛擬碼 ——>
看著好像沒啥問題吧，寫的還挺工整的，程式碼規範好評！
再看看後端怎麼樣。
後端
後端要做的事情就是接受前端發過來的請求，操作資料庫，將資料庫中指定 id 的訊息刪除，再返回是否刪除成功給前端。
存放訊息的資料庫
很多程式語言都可以拿來寫後端，比如 Java、Go 語言等。但由於小阿巴是第一次做後端，我心疼他，所以讓它使用 NodeJS（JavaScript 語法）來寫。
看看小阿巴寫的後端程式碼：
// 刪除訊息介面// @params msgId 訊息 idfunction deleteMsgById（msgId） { // 呼叫資料庫刪除函式，得到結果 const res = db。deleteById（msgId）； return res；}
總共就這麼幾行程式碼，簡潔清晰，也難怪小阿巴花了 3 天的時間就寫出來了。
不知道大家覺得這段程式碼怎麼樣，像不像自己第一次寫的程式碼呢？
請大家思考一下，他寫的程式碼有沒有什麼問題？
分析問題
其實，小阿巴這段程式碼問題非常大！一旦上線了，後果不堪設想！
主要有三個問題，我把小阿巴叫了過來，要根據問題的嚴重性從大到小給他盤一盤。
1。 未做校驗
我對小阿巴說：再仔細看看你的程式碼，是不是少了校驗邏輯？
小阿巴疑惑：我不是在前端判斷訊息 id 是否存在、訊息是否已讀了麼？
我：那如果使用者不在瀏覽器裡點刪除按鈕，而是直接請求介面，隨便傳訊息 id 呢？
小阿巴陷入了沉思。
這是第一次寫後臺的同學經常犯的錯誤，尤其是前後端都一個人寫的時候，以為在前端判斷引數是否合法就夠了。但其實，惡意使用者可不管這麼多，他們可以直接用各種工具在瀏覽器外向你的後端傳送請求，隨便傳一些訊息 id，甚至直接遍歷可能的 id。如果後端不做校驗，一上線，正常使用者的訊息可能就被刪光了！絕對的
最高階事故
！
小阿巴：沒想到這麼嚴重，那我在後臺補上對訊息狀態的校驗，好像也不太行吧？畢竟使用者可以任意傳遞請求引數。
我：挺聰明嘛，的確如此，所以我們還要補上對當前登入使用者的校驗。
完善的程式碼大致是這樣的：
// 刪除訊息介面// @params msgId 訊息 idfunction deleteMsgById（msgId） { // 校驗引數合法性 if （！mgsId） { return false； } // 從資料庫查訊息最新狀態 const msg = db。getMsgById（msgId）； // 從 session 或中介軟體獲取當前使用者資訊 const user = getCurrentUser（）； // 訊息未讀或不是該使用者的訊息 if （！msg。isRead || ！user || msg。userId ！== user。id） { return false； } // 呼叫資料庫刪除函式，得到結果 return db。deleteById（msgId）；}
小阿巴：我記住啦，後端介面是業務核心，一定要加強校驗！
我：不錯，來看看其他的問題吧。
2。 硬刪除
我：在你的程式碼中，直接呼叫了
delete
函式直接刪除資料，你知道這會有什麼問題麼？
小阿巴：有啥問題？
我：直接刪除資料，會導致管理員在需要排查問題時缺少線索。比如使用者傳送過違規訊息，一段之間後把訊息自己刪掉了，那管理員也不能查出他的違規記錄了。
小阿巴：還真是，那咋辦？這資料不能刪？
我：一般會採用
軟刪除
，給資料表新增一個額外的欄位來表示刪除狀態，比如
isDelete
，狀態為 0 表示未刪除，為 1 表示已刪除。正常情況下，只給使用者展示 isDelete = 0 的資料，刪除時，將該欄位的值從 0 更新為 1 即可。
所以上述程式碼的最後那部分，可以略作修改：
// 原始碼，真實刪除db。deleteById（msgId）// 新程式碼，軟刪除（更新）db。updateById（msgId， {isDelete： 1}）
這樣後端程式碼就基本完善了。
當然，也不是所有的資料表都需要軟刪除，要根據業務場景來決定。
3。 無防誤觸
最後還有一個產品體驗上的小問題，建議在使用者點選刪除時，出一個二次確認的彈框，否則使用者不小心點錯了，想找卻又找不回訊息，那就會感到憤怒了！
確認刪除
前端開發做的越多，就會越注重這些小細節，提升使用者體驗非常重要！
小阿巴：學到了，學到了！我好菜啊 555。
我：沒事，這是很正常的，知錯能改，就還是好阿巴。
很多正在閱讀文章的朋友們，是否也犯過這些小錯誤呢？請養成良好的程式設計習慣，多多檢查自己的程式碼吧！
對了，聽說點個
贊
，印象更深刻！
