大文件排序需分而治之：按字节阈值（如1.2gb）流式切块并在换行符处截断；内存中用指定比较器排序；归并时用priorityqueue控制多路读取，配合临时文件异常防护机制。
大文件排序不能靠一次性加载进内存硬排，核心是“分而治之”：先切块、再内存排序、最后归并。用集合作为缓冲区，本质是把 List、Queue 或 PriorityQueue 当作临时中转站，控制内存占用、避免 OOM，同时提升归并效率。关键不在集合类型本身，而在它怎么参与读、排、写、合四个环节。
按字节切块，别按行数硬分
20GB 日志里一行可能 1KB，也可能 100 字节——按固定行数切（如每 10 万行）会导致某些块远超内存限额。正确做法是估算可用内存（比如 1.5GB），预留 20% 给运行时开销，按字节阈值（如 1.2GB）流式读取，并在换行符 \n 处安全截断，确保不把一行劈成两半。可用 StreamReader.BaseStream.Read() 配合累计计数，比 ReadLine() 更可控。
排序阶段：集合只做暂存，比较逻辑要明确
读满一块后，数据进 List
- 纯 ASCII 时间戳前缀（如 2026-05-09T12:34:56）→ 用 StringComparer.Ordinal
- 含大小写混合的文件名（如 file10.txt 应排在 file2.txt 后）→ 用 StringComparer.OrdinalIgnoreCase 或自定义 IComparer
- 数值型字段（如日志中的响应时间毫秒）→ 先 int.TryParse() 提取再比，别字符串直比
归并阶段：用 PriorityQueue 控制多路读取
假设有 300 个已排序的临时块（chunk_001.tmp … chunk_300.tmp），传统方式为每个开一个 StreamReader，极易句柄耗尽或 GC 崩溃。改用 PriorityQueue：
- 初始化时，从每个块读首行，入队（优先级按 line 值）
- 每次 Dequeue() 取最小行，写入输出流
- 再从该行来源的块读下一行，重新入队
- 缓冲区满时批量刷盘，而非逐行 Write
这样最多只维持 300 个 StreamReader 实例，但活跃读取的只有队列大小（通常 1～2 行/块），内存峰值稳定可控。
临时文件与异常防护必须到位
所有中间文件不是随便命名写完就完事：
- 用 Path.GetTempFileName() 创建，系统自动保证唯一性和权限安全
- 每个临时块写完立刻 Flush() + Close()，防止崩溃时残留损坏文件
- 归并失败时，主动遍历并删除所有 *.tmp 文件，避免磁盘被占满
- 原始编码（如 UTF-8 BOM、GBK）需全程保持一致，否则归并时乱码直接导致排序错位
不复杂但容易忽略
