@PrinceofInj 我觉得 1 某种程度上算是个 magic number ，一看就知道是手机号。当然也可能是为了后续拓展到 2 留的……

是一个挺有意思的问题，也许可以要求 sum(nums[:10]) % k == nums[10] % k ，这样会使(k-1)/k 的号码被废弃
假设打错电话通常是按错一个数字，那 k=2 也够用了

听起来你已经激活了这台 MacBook Air ，那也没有退货的选项了（我理解国补+教育优惠应该不是 Apple 官方的平台买的），何不先用一段时间试试？别人并不清楚你真正的性能需求。旧设备可以先别急着置换，万一 M4 的 Air 有什么问题可以随时先换回去。如果最后发现性能足够但内存/硬盘不够，再换也来得及。

我用的是 Windows ，以前也尝试过多设备，后来发现都不如一台笔记本走天下。文件能通过网盘同步，但配置的环境、打开的窗口、微信等软件的登录状态，这些都不可能做到无缝切换。

@dya 盈透是必须用护照吗？

@Artpop 谢谢。ib 是指盈透证券对吧，“不用人在内地”是说“必须在香港吗”


@WasteNya 港股通要 50w 吧，没打算投这么多哈哈


@iampure 可以人在内地吗？

@Biggoldfish
@Muniesa
感谢二位，在主楼里 append 了一些信息

不了解最新的分布式架构，但感觉这也太符合 MapReduce 的思路了…

逻辑上：
1. 把文件扫一遍，得到 id->list[pair<content,sort>]的映射。
2. 单独为每个 id 的内容做内部排序。

实现上：
1.无论用什么方法，一轮文件 IO 把数据都进来都是需要的。为了后续处理更方便，再多加一轮 IO ，先把大文件按 1<id<10w, 10w+1<id<20w...切成多个小文件，这样每个小文件都是独立的，后续处理时维护的中间状态会少很多。
2. 每个小文件用一个进程处理，得到 id->list[pair<content,sort>]的中间结果。要么像楼上说的直接进数据库，要么每个 id 的内容放在一个文件里。一个小文件跑完后就可以从中间结果生成最终数据了。

并行度可以在切小文件的时候控制（每个小文件 10w 还是 100w 个 id ）。

前提：
你存放最终结果的数据库需要能承受这么大的最终数据，否则啥办法都白搭。