幽默輕松小知識(shí)，一起來(lái)看看老弟第一次寫(xiě)的后端代碼，你覺(jué)得如何？

大家好，我是魚(yú)皮，今天分享我的老弟第一次寫(xiě)后端代碼時(shí)出現(xiàn)的囧事，希望大家引以為戒。

孽起

我的老弟小阿巴，目前大一，自學(xué)編程有一段時(shí)間了，之前主要以學(xué)前端為主，比較好上手。

但這貨最近不知道咋回事，一直嚷嚷著要寫(xiě)寫(xiě)后端代碼。

我說(shuō)：你前端才剛學(xué)沒(méi)多久呢，急什么？

小阿巴說(shuō)：沒(méi)人比我更懂前端！

好家伙，沒(méi)想到幾日不見(jiàn)，這家伙現(xiàn)在這么驕傲了！那必須得殺殺他的銳氣，讓他領(lǐng)略一下后端的恐怖。

于是我說(shuō)：成，正好我最近在開(kāi)發(fā)一個(gè)新功能【刪除消息】，功能很簡(jiǎn)單，允許用戶刪除自己已經(jīng)閱讀過(guò)的消息。前端后端都交給你來(lái)做，時(shí)間也不急，給你兩周，拿去練練手，熟悉下項(xiàng)目吧~

沒(méi)想到小阿巴這狗說(shuō)：兩周？瞧不起誰(shuí)呢，就這么一個(gè)小功能，我 3 天給你搞定！

我大驚：現(xiàn)在的年輕人都這么強(qiáng)了么？行，我等你！

沒(méi)想到，不到 3 天，小阿巴真的提交了代碼，讓我們一起來(lái)看看他的實(shí)現(xiàn)思路和代碼吧。

實(shí)現(xiàn)思路

功能實(shí)現(xiàn)包括前端和后端兩部分，分別來(lái)思考一下。

前端

要實(shí)現(xiàn)用戶已讀消息刪除功能，前端的工作比較簡(jiǎn)單，添加一個(gè)刪除按鈕，并且給按鈕添加一個(gè)點(diǎn)擊事件，點(diǎn)擊后調(diào)用后端 消息刪除 接口即可。

小阿巴寫(xiě)的前端代碼：

<!--?偽代碼?-->
<button?onClick={doDelete(消息)}>刪除</button>
<script>
??//?刪除消息
??function?doDelete(msg)?{
????//?消息?id?存在且為已讀
????if(msg.id?&&?msg.isRead)?{
??????//?調(diào)用后端接口
??????service.deleteMsgById(msg.id);
????}
??}
</script>


看著好像沒(méi)啥問(wèn)題吧，寫(xiě)的還挺工整的，代碼規(guī)范好評(píng)！

再看看后端怎么樣。

后端

后端要做的事情就是接受前端發(fā)過(guò)來(lái)的請(qǐng)求，操作數(shù)據(jù)庫(kù)，將數(shù)據(jù)庫(kù)中指定 id 的消息刪除，再返回是否刪除成功給前端。

很多編程語(yǔ)言都可以拿來(lái)寫(xiě)后端，比如 Java、Go 語(yǔ)言等。但由于小阿巴是第一次做后端，我心疼他，所以讓它使用 NodeJS（JavaScript 語(yǔ)法）來(lái)寫(xiě)。

看看小阿巴寫(xiě)的后端代碼：

//?刪除消息接口
//?@params?msgId?消息?id
function?deleteMsgById(msgId)?{
??//?調(diào)用數(shù)據(jù)庫(kù)刪除函數(shù)，得到結(jié)果
??const?res?=?db.deleteById(msgId);
??return?res;
}


總共就這么幾行代碼，簡(jiǎn)潔清晰，也難怪小阿巴花了 3 天的時(shí)間就寫(xiě)出來(lái)了。

不知道大家覺(jué)得這段代碼怎么樣，像不像自己第一次寫(xiě)的代碼呢？

請(qǐng)大家思考一下，他寫(xiě)的代碼有沒(méi)有什么問(wèn)題？

分析問(wèn)題

其實(shí)，小阿巴這段代碼問(wèn)題非常大！一旦上線了，后果不堪設(shè)想！

主要有三個(gè)問(wèn)題，我把小阿巴叫了過(guò)來(lái)，要根據(jù)問(wèn)題的嚴(yán)重性從大到小給他盤(pán)一盤(pán)。

1. 未做校驗(yàn)

我對(duì)小阿巴說(shuō)：再仔細(xì)看看你的代碼，是不是少了校驗(yàn)邏輯？

小阿巴疑惑：我不是在前端判斷消息 id 是否存在、消息是否已讀了么？

我：那如果用戶不在瀏覽器里點(diǎn)刪除按鈕，而是直接請(qǐng)求接口，隨便傳消息 id 呢？

小阿巴陷入了沉思。

這是第一次寫(xiě)后臺(tái)的同學(xué)經(jīng)常犯的錯(cuò)誤，尤其是前后端都一個(gè)人寫(xiě)的時(shí)候，以為在前端判斷參數(shù)是否合法就夠了。但其實(shí)，惡意用戶可不管這么多，他們可以直接用各種工具在瀏覽器外向你的后端發(fā)送請(qǐng)求，隨便傳一些消息 id，甚至直接遍歷可能的 id。如果后端不做校驗(yàn)，一上線，正常用戶的消息可能就被刪光了！絕對(duì)的 最高級(jí)事故！

小阿巴：沒(méi)想到這么嚴(yán)重，那我在后臺(tái)補(bǔ)上對(duì)消息狀態(tài)的校驗(yàn)，好像也不太行吧？畢竟用戶可以任意傳遞請(qǐng)求參數(shù)。

我：挺聰明嘛，的確如此，所以我們還要補(bǔ)上對(duì)當(dāng)前登錄用戶的校驗(yàn)。

完善的代碼大致是這樣的：

//?刪除消息接口
//?@params?msgId?消息?id
function?deleteMsgById(msgId)?{
??//?校驗(yàn)參數(shù)合法性
??if?(!mgsId)?{
????return?false;
??}
??//?從數(shù)據(jù)庫(kù)查消息最新?tīng)顟B(tài)
??const?msg?=?db.getMsgById(msgId);
??//?從?session?或中間件獲取當(dāng)前用戶信息
??const?user?=?getCurrentUser();
??//?消息未讀或不是該用戶的消息
??if?(!msg.isRead?||?!user?||?msg.userId?!==?user.id)?{
????return?false;
??}
??//?調(diào)用數(shù)據(jù)庫(kù)刪除函數(shù)，得到結(jié)果
??return?db.deleteById(msgId);
}


小阿巴：我記住啦，后端接口是業(yè)務(wù)核心，一定要加強(qiáng)校驗(yàn)！

我：不錯(cuò)，來(lái)看看其他的問(wèn)題吧。

2. 硬刪除

我：在你的代碼中，直接調(diào)用了 delete 函數(shù)直接刪除數(shù)據(jù)，你知道這會(huì)有什么問(wèn)題么？

小阿巴：有啥問(wèn)題？

我：直接刪除數(shù)據(jù)，會(huì)導(dǎo)致管理員在需要排查問(wèn)題時(shí)缺少線索。比如用戶發(fā)送過(guò)違規(guī)消息，一段之間后把消息自己刪掉了，那管理員也不能查出他的違規(guī)記錄了。

小阿巴：還真是，那咋辦？這數(shù)據(jù)不能刪？

我：一般會(huì)采用 軟刪除，給數(shù)據(jù)表添加一個(gè)額外的字段來(lái)表示刪除狀態(tài)，比如 isDelete，狀態(tài)為 0 表示未刪除，為 1 表示已刪除。正常情況下，只給用戶展示 isDelete = 0 的數(shù)據(jù)，刪除時(shí)，將該字段的值從 0 更新為 1 即可。

所以上述代碼的最后那部分，可以略作修改：

//?原代碼，真實(shí)刪除
db.deleteById(msgId)
//?新代碼，軟刪除（更新）
db.updateById(msgId,?{isDelete:?1})


這樣后端代碼就基本完善了。

當(dāng)然，也不是所有的數(shù)據(jù)表都需要軟刪除，要根據(jù)業(yè)務(wù)場(chǎng)景來(lái)決定。

3. 無(wú)防誤觸

最后還有一個(gè)產(chǎn)品體驗(yàn)上的小問(wèn)題，建議在用戶點(diǎn)擊刪除時(shí)，出一個(gè)二次確認(rèn)的彈框，否則用戶不小心點(diǎn)錯(cuò)了，想找卻又找不回消息，那就會(huì)感到憤怒了！

前端開(kāi)發(fā)做的越多，就會(huì)越注重這些小細(xì)節(jié)，提升用戶體驗(yàn)非常重要！

小阿巴：學(xué)到了，學(xué)到了！我好菜啊 555。

我：沒(méi)事，這是很正常的，知錯(cuò)能改，就還是好阿巴。

很多正在閱讀文章的朋友們，是否也犯過(guò)這些小錯(cuò)誤呢？請(qǐng)養(yǎng)成良好的編程習(xí)慣，多多檢查自己的代碼吧！

對(duì)了，聽(tīng)說(shuō)點(diǎn)個(gè) 贊，印象更深刻！