“两个巨大文件，大小远超内存，怎么比较？”这类题看起来像算法题，其实更像系统题。面试官想看的不是你能不能说出一个技巧，而是你会不会先澄清约束：比较的是字节完全相同，还是比较每一行集合相同；是否允许近似；文件是否有重复行；磁盘空间是否足够；能否多机处理。
如果一上来就说“用 HashMap 存起来”，基本说明没有把规模条件放进脑子里。数据远超内存时，核心思路是把一次装不下的问题拆成多次顺序读写、分桶、排序或流式校验。
先区分比较语义
如果只是判断两个文件字节内容是否完全一致，最直接的方式是比较大小，再顺序读取块做校验。可以计算强哈希摘要，实际工程里碰撞概率极低，但严格意义上哈希相等不等于数学上百分百相同；如果要绝对确认，最终仍可逐块比较。
如果比较的是两份日志里“行集合是否相同”，问题就变复杂了。行顺序是否重要、重复行是否要计数、空格和编码是否归一化，都会影响方案。很多候选人答错，不是算法不会，而是没有先定义“相同”。
外部排序适合精确比较
当需要比较每一行且重复次数也要一致时，外部排序是稳妥方案。把文件按内存可承受大小切成多个块，分别排序后写临时文件，再做多路归并，最后逐行比较两个排序后的结果。
这个方案的优点是语义清晰，重复行天然能比较出来；缺点是需要额外磁盘空间，IO 成本较高。面试里要说出这些代价，而不是只报“外排序”三个字。真实系统里还要考虑临时文件清理、磁盘满了怎么办、排序键如何解析、编码异常如何处理。
哈希分桶能减少单次内存压力
另一种思路是按行内容的哈希值分桶。把两个文件分别扫描一遍，把相同行理论上落到同一个桶里。然后逐个桶加载到内存或排序比较。只要桶数量足够，单个桶就能控制在内存范围内。
这里要注意两个边界。第一，哈希分桶不是直接比较哈希值，而是把数据分组，桶内仍要精确比较原始行和重复次数。第二，数据分布可能倾斜，某些热点行或相似前缀会让桶过大，需要二次分桶或桶内外排序。
近似方案要明确风险
有些场景不需要绝对精确，比如快速判断两个海量集合大概率是否一致，可以用 Bloom Filter、采样或分段校验。但 Bloom Filter 有误判，不适合财务对账、审计、库存这种强一致场景。
面试里提近似方案不是坏事，前提是主动说清业务是否允许误判。如果题目没有说允许近似，默认应该给出精确方案，再补充近似方案可以用在预筛或监控。
工程实现里的细节
超大文件处理最容易被忽略的是 IO 模式。顺序读写通常比随机读写友好；临时文件目录要有空间监控；单机处理要控制并发，避免把磁盘打满；多机处理要保证同一分桶规则和最终归并校验。
一个好的回答可以这样收尾：我会先确认比较语义和准确性要求；字节级相同用大小加流式校验；行集合相同用外部排序或哈希分桶加桶内精确比较；如果业务允许近似，再用 Bloom Filter 或摘要做预筛。这样，这道题就从“会不会算法”变成了“能不能处理真实规模”。