@waibunleung 不知道你写了这么多有什么好指点的，跟你聊真是浪费时间，多试就完事了

@waibunleung 你当然无法从我的回答总结出经验，纸上谈兵谈不出兵，你跑一跑当然就有经验了。比如你这个例子里，正常开发对于不同数据库的负载能力心里有个量级，比如如果表内有 30 万行，大多数情况下我不会太在意搜索性能，而 3000 万行对于 mysql 单表来说属于稍大的量级，需要给予一些关注，同理如果是 oracle 那又是另一种情况，我是这个意思。具体说到存储的话，单表不说明问题，具体与分区分表和你的业务高度绑定，当然只有你自己知道多快，不过你写 sql 语句的时候通过估算复杂度可以估算出一个大概的量级，比如 a 语句会低延迟返回，b 语句需要花费若干秒，c 语句需要若干分钟等等，按数量级估算当然是开发的基本功。我说集群负载能力的意思是根据你集群方式的不同负载能力的增幅当然不是线性的。

同理关系型数据库是这样，对业务中其他环节你都应该有这样的估算，比如上述所谓 a 语句低延迟返回，这也是少数有可能造成其他环节瓶颈的业务，就需要更量化的分析。

@waibunleung 我觉得你这样问没什么意思，问也问不出什么。我的意思是作为开发，常用的工具链最起码要搞熟，一般一个网络服务中有若干个子服务，比如网关、业务、缓存、（虚拟的）数据层，这些不用挨个罗列是所有人都知道的事，搞熟的意思最起码你要知道每个框架作为工具的负载能力，你比如你在调数据库业务的时候，你知道表有多大，什么储存方式，业务如何索引，集群的负载增幅是多少，那你应该能估算出单节点大概的时间范围，其他环节同理，遇到特殊情况完全估算不出的那不妨测一测。我的意思是这么简单的道理，为什么要问呢。

收藏数多大概是因为 LZ 问题问的不错，以后遇到初级开发可以让他挨个点考教

1 和 6 不是开发考虑的问题，2 和 4 的大概值估算是开发的基本功，写代码时候就知道大概是多少了，想知道具体值可以压测，5 的网关性能瓶颈几乎没见哪个业务遇到过，业务量大到这个份上还搞不清瓶颈在哪里比较玄学。7 多学习

您这是不是应该发到推广版？

steampy 观感非常差，强烈怀疑运营收集账号密码有恶意目的，我试着买了个 cdkey，既然是 cdkey 自然是一手交钱一手交货的简单交易，但实际购买后必须绑定 steam 账号才能领卡，且绑定 steam 账号也不是 oauth2，而是需要直接提供账号和密码才能绑定，居心何在？

我直接发工单问给不给退货了，不给退消协投诉。

@amezf 这网站为什么绑定账号还要输入 steam 密码的？密码可以随便给人？

@colarxu 忘说了，不考虑换区的情况下

@Charrlles 感谢，很清晰。不过看楼上说的 indexedDB 好像很符合我的需求，不知道 serviceworker 和这个有什么侧重点的不同，感觉好像挺重叠的

@Elethom 还有一个问题，前端储存的话是不是表示放弃了多端同步的需求

@Jooooooooo 限制数量是一个简单粗暴的方案，我只是想知道 v2 怎么实现的，毕竟这种规模的业务也不算小了，挺有参考意义的