持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第7天，点击查看活动详情
背景
遥想当年在贴吧碰到一个要写毕业设计的妹妹，抱着学习后端的初衷，跟她合作一个校园二手交易市场。
后端技术栈为：node、koa、MongoDB。除了真实的支付跟快递没搞，然后商家认证简陋了点，基本上整个闭环是通的，但是太野路子了，现在回头看，好多地方写得太幼稚，最值得吐槽的就是，用 MongoDB 去写这种交易市场，嘻嘻
点击删除当然是要从数据库里删除啦
“点击删除当然是要从数据库删除啦”，设计消息模块的时候，我脑子正是这样想，也是这样去做。
用户评论消息点击删除，数据库直接把它删除掉
订单消息点击删除，数据库直接把它删除掉
公告消息点击删除，数据库直接把它删除掉
咦，怎么用户b看不到公告消息了，只是用户a删了公告，按道理，除了用户a其他用户都能看得到才对啊。脑海里电波一闪，浮现出“软删”这个词。一些全局性的业务消息，不应该让用户直接从数据库上删除，这样会造成上述问题。
软删除
一开始的时候，我已经对消息做了分类，为了达到软删效果，对例如公告类型的消息，做一些改造：
- 为消息表添加一个deleteUserID的字段，用来储存软删的userid
- 对删除添加额外处理，对特定类型消息调用软删逻辑，将用户的userid放到deleteUserID里面
- 消息列表接口增加额外逻辑，返回当前用户id没有与deleteUserID相匹配的消息
这样就大功告成啦。生成一条公告后，再让用户a删除，这时候只会把用户a的userid记录到该条消息的deleteUserID里面，然后用户b还是可以看到的，但是用户a已经看不到了,因为通过条件3判断，该公告已经被过滤
