文件按手机号排序，取手机号前 7 位(万号段)第一次出现的偏移量，放入数组。
行数小于 1000w （ 2^20),一行字节数小于 4k(2^12)，4 字节可以存一个偏移量；手机号前两位固定为 13/17/18，所以前 7 位 30 万排列组合，使用 1.2M 内存。
查询时先取该万号段和下一万号段偏移量，然后在文件中二分查找。

还可以优化：
1 、将 name 用空格补齐到固定长度，可以直接用行数乘以每行长度得到偏移量，这样 3 字节就可以存一个行数，更省内存。(虽然不知道抠这点内存有啥意思)
2 、既然对响应时间没有要求，剩下内存可以对请求做一个队列，按请求的手机号做排序然后批处理查询，保证每次批处理时文件扫描从头到尾或从尾到头，增加随机访问效率。

@maomaomao001 网页打开的话，500 到 5000 很明显，50 到 500 能感知，不明显。

@drxiaomao base64 解码一下

3 小时撸了 100 行代码完成，无任何依赖，直接页面拿走去玩吧。
aHR0cCUzQS8vdG9vbC51Y21hcmlvLmNvbS9saXppLmh0bWw=

理论上应该是可以的，通过降低挖矿难度，比如运算结果要求 128 位中前 100 位为 0，那么你要求前 60 位为 0 即可通过，找答案的算力要求降到挖矿的 1/2^40，来让用户可以在小片时间算出来。
然后从这些结果中找是不是有天选之子提供的答案有前 100 位为 0 的，有 （ 1/2^40 * 访问量） 的几率挖矿成功哦。

有没有怀疑是 K2P 的问题？
我的 K2P 刷 Merlin 了之后信号就有问题。

服务端存上一次访问时的时间和存量。
登录时发给客户端。
用户查看时客户端自己算。
交互时服务端结算。

@Meiyun 现在几个站会员各种套娃，也就 B 站还良心。而且有些东西看完过一阵下架，再找就没了。

很正常啊，前后端分离，我有几个相似的基础接口前端 n 个地方调，我知道他哪个功能调的哪个？

你可以买个很便宜的二手车上牌，买了新车，二手车卖掉或报废，车牌转过去新车。

个人理解。
车牌跟行驶证对应，行驶证对应车，所以没车办不了车牌。
某些地区摇号，是摇办车牌的资格，有了资格才能给车上牌。有资格没车还是办不了车牌。一般摇到号 n 个月不买车资格就作废了。跟你情况类似。
以上。

这个场景用，涉及多线程交互。直观方法是 exchanger，或者用通知队列。
当年看的《如何造火箭》，还是能派上用场的。

@nnnToTnnn 认为 B 更优的根据是作为 data exchange 格式, B 比 A 层级少, 且明确表示携带了数据的顺序信息.

很明显大多数人没有搞清楚字面量对象和 json 之间的区别。如果作为字面量对象，A 和 B 没有高下，只是使用场景不同。作为 json，B 更好。

企业招人更多是看是否适合，是否去一线主要看自己想要什么节奏的生活。