前端老弟第一次写后端，崩了 _后端

大家好，我是鱼皮，今天分享我的老弟第一次写后端代码时出现的囧事，希望大家引以为戒。
孽起我的老弟小阿巴，目前大一，自学编程有一段时间了，之前主要以学前端为主，比较好上手。
但这货最近不知道咋回事，一直嚷嚷着要写写后端代码。
我说：你前端才刚学没多久呢，急什么？
小阿巴说：没人比我更懂前端！
好家伙，没想到几日不见，这家伙现在这么骄傲了！那必须得杀杀他的锐气，让他领略一下后端的恐怖。
于是我说：成，正好我最近在开发一个新功能【删除消息】，功能很简单，允许用户删除自己已经阅读过的消息。前端后端都交给你来做，时间也不急，给你两周，拿去练练手，熟悉下项目吧~
【前端老弟第一次写后端，崩了】没想到小阿巴这狗说：两周？瞧不起谁呢，就这么一个小功能，我 3 天给你搞定！
我大惊：现在的年轻人都这么强了么？行，我等你！
没想到，不到 3 天，小阿巴真的提交了代码，让我们一起来看看他的实现思路和代码吧。
实现思路功能实现包括前端和后端两部分，分别来思考一下。
前端要实现用户已读消息删除功能，前端的工作比较简单，添加一个删除按钮，并且给按钮添加一个点击事件，点击后调用后端消息删除接口即可。

文章插图

前端界面
小阿巴写的前端代码：

<!-- 伪代码 --><button onClick={doDelete(消息)}>删除</button><script>  // 删除消息  function doDelete(msg) {    // 消息 id 存在且为已读    if(msg.id && msg.isRead) {      // 调用后端接口      service.deleteMsgById(msg.id);    }  }</script>

看着好像没啥问题吧，写的还挺工整的，代码规范好评！
再看看后端怎么样。
后端后端要做的事情就是接受前端发过来的请求，操作数据库，将数据库中指定 id 的消息删除，再返回是否删除成功给前端。

文章插图

存放消息的数据库
很多编程语言都可以拿来写后端，比如 JAVA、Go 语言等。但由于小阿巴是第一次做后端，我心疼他，所以让它使用 NodeJS（JavaScript 语法）来写。
看看小阿巴写的后端代码：

// 删除消息接口// @params msgId 消息 idfunction deleteMsgById(msgId) {  // 调用数据库删除函数 ， 得到结果  const res = db.deleteById(msgId);  return res;}

总共就这么几行代码，简洁清晰，也难怪小阿巴花了 3 天的时间就写出来了。
不知道大家觉得这段代码怎么样，像不像自己第一次写的代码呢？
请大家思考一下，他写的代码有没有什么问题？

分析问题其实，小阿巴这段代码问题非常大！一旦上线了，后果不堪设想！
主要有三个问题，我把小阿巴叫了过来，要根据问题的严重性从大到小给他盘一盘。

1. 未做校验我对小阿巴说：再仔细看看你的代码，是不是少了校验逻辑？
小阿巴疑惑：我不是在前端判断消息 id 是否存在、消息是否已读了么？
我：那如果用户不在浏览器里点删除按钮，而是直接请求接口，随便传消息 id 呢？
小阿巴陷入了沉思。
这是第一次写后台的同学经常犯的错误，尤其是前后端都一个人写的时候，以为在前端判断参数是否合法就够了。但其实，恶意用户可不管这么多，他们可以直接用各种工具在浏览器外向你的后端发送请求，随便传一些消息 id ，甚至直接遍历可能的 id 。如果后端不做校验，一上线，正常用户的消息可能就被删光了！绝对的最高级事故！