小阿巴：没想到这么严重 ， 那我在后台补上对消息状态的校验 ， 好像也不太行吧？毕竟用户可以任意传递请求参数 。
我：挺聪明嘛 ， 的确如此 ， 所以我们还要补上对当前登录用户的校验 。
完善的代码大致是这样的：
// 删除消息接口// @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. 无防误触最后还有一个产品体验上的小问题 ， 建议在用户点击删除时 ， 出一个二次确认的弹框 ， 否则用户不小心点错了 ， 想找却又找不回消息 ， 那就会感到愤怒了！
文章插图
确认删除
前端开发做的越多 ， 就会越注重这些小细节 ， 提升用户体验非常重要！
推荐阅读
- Bootstrap5.0-全球流行的前端开源UI工具包迎来了大版本更新
- 微星|史上第一次5位数！DDR5内存频率突破10000MHz
- 推荐几个抓包类工具的下载
- 男人最在意哪个第一次
- 小孩连裤袜
- vscode 前端常用插件推荐
- npm简介
- 初次逛漫展3大禁忌是什么？
- 第一次去新疆旅游应该参观那些景点
- 低成本可复用前端框架——Linke