金雄镕

如果没有 分队/核心干员/标签 的信息，那数据搜索会有点困难，搜索时可能只能通过攻略中的文本内容搜索了。我们也不支持分词搜索，没法像搜索引擎一样按照多个词语匹配。

> > 项目新人，请教一下，我看代码中已经有关闭或开放评论的接口了（`copilot/ban`)，所以对于转换需求1和2中类似的需求是已经完成了对吗。所以需求其实是：1. 主评论通知 2. 作者本人永远可评论 > > 没事了好像作者本人可以评论也是通过userid和uploadid的判断完成了，所以其实这个需求是完成了的是吧。如果是的话请忽略我上面的提问 完成了的，但是前端那边设计上和需求有点区别。抱歉没更新说明。

没有计划，尽量用mongodb做吧，用图数据库还得多吃服务器资源。如果有想法的话可以在本 issue 留下设计思路，或者直接建立 wip pr

> 然后就是既然是想实现关注功能，应该更多的是想实现关注者作业优先展示，以及新作业的通知？ 通知不做，邮箱服务是白嫖的，每日发送邮件的数量比较有限，而且做了通知就得有关注但是不接收邮件的选项，对于单个改动来说变得复杂了。

> * 关注/取消关注 用户 > > * 获取关注/粉丝列表 > > * 获取关注/粉丝数量 > > * 判断是否已关注 有一个比较重要的功能是只查看我关注的作者的作业，要放到查询作业列表的功能里。

@Handiwork 佬，你有什么看法，现在两位的实现存在差别。 方案1：直接把粉丝列表和关注列表放到用户信息上，以mongodb的使用方式来讲好像也挺合理的，我个人在没什么mongodb的其他经验，不确定是否是这样。 方案2：单独建立关注关联关系表，和一般的关系型数据库一样的用法。 个人认为两种实现都行，不过绑定到用户对象的做法还需要同步改进历史的代码，查询时需要指定投影，减少数据传输。

> 4. 每次进行 follow/unfollow 操作时，更改的是 follower 的 following 列表和 followee 的 followed 列表，分别来自两个用户；用户侧同时读取两个列表的场景又几乎不可能出现，因此两者拆开更为方便 这点是说单个文档直接存储列表，每个人建立两条数据吗？还是一个人关注多人分成多条数据再聚合？

Maa 可以加载作业说明连接是无问题的，可能代理使用了 fake-ip 之类的技术，导致浏览器缓存了错误的 ip，建议尝试使用代理工具的同时使用直连模式查看是否正常