最轻量可控的文本文件行排序是「读→排→写」三步：小文件用bufio.Scanner读入[]string后sort.Slice排序，禁用随机比较函数；合并多文件必须用io.Copy流式处理，配合零填充命名或数字提取排序防错位。
直接用 sort.Slice 对内存中读取的行切片排序，再用 io.Copy 流式合并多个文件——这是最轻量、最可控的组合。别碰 os.ReadFile 处理大文件，也别用 sort.Slice 配随机比较函数打乱行序。
如何安全地对文本文件按行排序
所谓“行排序”，本质是把文件按行读进内存、排序、再写出。Go 没有原地行排序系统调用，必须走「读→排→写」三步。
- 小文件（≤10MB）：用
bufio.Scanner或bufio.NewReader逐行读取到[]string，再调用sort.Slice - 避免用
strings.Split(string(b), "\n")解析大文件内容——会多一次完整字符串拷贝，且无法处理超长行 - 排序函数里必须检查行长度：
if len(lines[i]) == 0 || len(lines[j]) == 0，否则空行或截断行会导致 panic - 若需数值排序（比如日志时间戳列），别直接比字符串：
strconv.Atoi转换后再比；失败时 fallback 到字典序，别让整个排序崩溃
合并多个文件时为何顺序总出错
因为 filepath.Glob("part_*.txt") 或 os.ReadDir 返回的是字典序，不是自然序。你看到 part_1.txt、part_10.txt、part_2.txt，实际加载顺序就是 1 → 10 → 2，数据立刻错位。
- 正确做法是提取数字：用
strings.TrimPrefix+strconv.Atoi解析每个文件名里的序号 - 再用
sort.Slice(files, func(i, j int) bool { return idx[i] < idx[j] })显式重排 - 生成分片时就强制零填充（
fmt.Sprintf("part_%03d.txt", i)），比运行时解析更可靠 - 永远别依赖文件系统返回顺序——ext4、NTFS、FAT32、NFS 行为全不一致
为什么不能用 ioutil.ReadFile 合并大文件
它会把整个文件读进内存，1GB 文件 = 1GB 堆分配。GC 压力陡增，runtime 直接报 out of memory，尤其在容器或低配机器上必崩。
立即学习“go语言免费学习笔记（深入）”；
- 替代方案只有
io.Copy：源文件os.Open，目标文件用os.OpenFile(dst, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644) - 追加场景才用
os.O_APPEND；覆盖场景必须带os.O_TRUNC，否则旧内容残留导致二进制损坏 -
io.Copy内部默认缓冲区 32KB，足够快；如需压低 I/O 峰值，可包一层bufio.NewReaderSize(src, 1<strong><code>MB</code></strong>) - 合并完务必调用
dst.Sync()，防止断电或 crash 导致末尾几 KB 丢失
真正容易被忽略的点是：排序和合并是两个独立阶段，但它们共享同一个脆弱前提——文件名解析逻辑必须完全一致。你在合并前怎么提数字，排序前就得怎么提；否则 part_001 和 part_1 被当成不同文件，数据就永远对不上。
