Greasy Fork

很不错。就是每次扫描动态列表可能会耗点时间。
我打算加个缓存机制，以用户的bid为键，标签作为值。
每次扫描前询问一次自己的服务器，看是否存在，存在则取数据库中信息，若不存在，则扫描动态详情。
往下延伸可以弄一个霹雳霹雳信息库

很不错。就是每次扫描动态列表可能会耗点时间。
我打算加个缓存机制，以用户的bid为键，标签作为值。
每次扫描前询问一次自己的服务器，看是否存在，存在则取数据库中信息，若不存在，则扫描动态详情。
往下延伸可以弄一个霹雳霹雳信息库

理论上可行，但维护服务器需要额外的成本，且中心化的服务器有被叔叔干碎的可能性，不过确实可以考虑基于localStorage的本地缓存机制。我最近没什么空闲时间，你有能力的话可以自己试试看？
此外，用户成分的时效性也很强，缓存会造成用户标签的更新延迟，导致无法对最新或最近的动态做出响应，如何优雅地处理时效性关系也值得探究。

服务器地址确实不能暴露，可能还涉及绿尸寒等问题，所以打算自己做着玩。
基于localStorage 存储量有点小，还是打算存储到数据库。
时效性我是这么考虑，这个人曾经是一个原，如果后续不再是原，该标签依旧有一定得标识性，不能因为时间过去后他的成分发生变化，就抛弃曾经的判断，依旧可以作为一个判断信息，比如曾经是原，后续可能也会是相关手游的用户，可以加个类型，置灰处理。
后端做成一个时间线的形式，每次查询给予现在的标签，以及曾经的标签
另外实时统计动态的方式可能也许比较麻烦，计划是 每日定时爬取某些用户，对状态进行更新。然后进入一个视频，获取一页用户的bid，统一发送给后端，然后直接批量返回用户的标签,如果要查询的用户的bid不存在，就让前端统计（分散计算压力），把结果返回给后端（多个用户缓存处理再发送）这样对带宽以及服务器的压力都较小。

以上都是一些设想，实现的花费的精力还是比较多。几个问题没有解决掉：
1,如果只给自己用，那么用户量较小，不能形成一个较为全面的数据库。
2,如果要爬取，需要获取足够的代理，并且要一个有效的爬取通道，确保获取的是较活跃的用户的信息

如果真的开坑了到时候再邀请你一起参与