为什么不能直接用 std::sort 处理超大文件？
因为内存装不下。当数据量远超可用 RAM（比如 100GB 文件跑在 16GB 内存机器上），std::sort 会触发大量 page fault，实际变成磁盘抖动排序，比归并慢一个数量级。外部排序不是“换种写法”，而是必须把 I/O 模式从随机读写切换为顺序读写——这是性能分水岭。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 单块大小通常设为
available_memory / 2（留一半给归并缓冲区），避免 OOM 或频繁 swap - 不要用
std::vector一次性读全量；改用固定大小的std::array<T, BLOCK_SIZE>或裸new T[BLOCK_SIZE]避免 vector 动态扩容开销 - 用
mmap+MAP_POPULATE加载块可减少缺页中断，但需确认 OS 支持且文件系统非 network-mounted
如何保证多路归并时不卡在磁盘寻道？
归并阶段的瓶颈不在 CPU，而在多个输入流的磁盘 head 竞争。如果每个块都单独打开一个 std::ifstream，操作系统很难合并成顺序读取，实际退化为随机 IO。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 预分配一个大缓冲区（如 4MB），用单个
std::ifstream顺序读取所有块的头部元数据（起始偏移、长度、最小值），构建归并堆 - 归并时只维护
std::priority_queue存指针/迭代器，真正读数据用预读缓冲区 + 手动read()调用，绕过 streambuf 的额外拷贝 - 输出也必须用带缓冲的
write()直接写裸字节，禁用std::ofstream的格式化开销
std::stable_sort 在块内排序中真有必要吗？
没必要，而且有害。外部排序只要求最终全局有序，块内是否稳定对结果无影响；但 std::stable_sort 平均时间复杂度更高（通常是 mergesort 实现），还强制要求额外 O(n) 临时空间，在内存受限场景直接抬高崩溃风险。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 块内一律用
std::sort（introsort），它在小数组自动切到 insertion sort，cache 局部性更好 - 若原始数据含等值键且业务要求“先入先出”，应在写入块前打上递增序列号，排序时作为第二关键字：
std::sort(..., [](const auto& a, const auto& b) { return std::tie(a.key, a.seq) - 避免在块排序中使用 lambda 捕获大对象或调用虚函数——编译器可能无法内联，导致每元素多一次函数调用开销
临时文件路径和清理为什么总出错？
常见错误不是逻辑错，而是路径没权限、磁盘满、或程序崩溃后残留临时文件锁死后续运行。C++ 标准库不提供原子临时文件创建，std::tmpfile() 又不支持 mmap 和大文件。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
mkstemp()（Linux/macOS）或GetTempFileName()（Windows）生成唯一路径，立即unlink()或DeleteFile()，靠 fd 保持文件存在——这样即使崩溃，OS 也会自动回收 - 临时文件务必和最终输出放在同一挂载点，避免跨设备
rename()失败 - 每次打开临时文件加
O_CLOEXEC（Linux）或FILE_FLAG_NO_BUFFERING（Windows），防止 fork 后子进程误继承句柄
真正的难点从来不在算法本身，而在于让每一块内存、每一次 read/write、每一个临时文件句柄，都处于你明确控制的状态。稍有松懈，IO 就会悄悄把你拖回 O(n²) 的泥潭。
