大文件切片不能直接用 os.ReadFile 因其会一次性加载全部内容致 OOM；应使用 os.Open 配合 bufio.NewReader、io.CopyN 或手动 Read/Write 控制块大小（1MB–16MB），注意偏移量管理与并发安全。
大文件切片为什么不能直接用 os.ReadFile
因为 os.ReadFile 会把整个文件一次性加载进内存，一个 2GB 的日志文件就可能直接 OOM。真实场景里，切片不是为了“读完再分”，而是边读边分块、避免内存暴涨。
正确做法是用 os.Open 获取文件句柄，配合 io.CopyN 或手动 Read + Write 控制每次处理的字节数。
- 优先用
bufio.NewReader包装*os.File，提升小块读取效率 - 切片大小建议设为 220（1MB）到 224（16MB），太小增加系统调用开销，太大仍占内存
- 注意文件偏移量：用
file.Seek(offset, io.SeekStart)精确跳转，比顺序读更可控
按固定字节长度切片的可靠实现
这是最常用也最容易出错的方式——看似简单，但边界处理不严谨会导致最后一块缺失或重复写入。
关键点在于：别依赖 io.CopyN 的返回值是否等于预期长度来判断是否结束；它在 EOF 时返回实际拷贝数，可能小于请求长度，但不报错。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 每次调用
io.CopyN前先检查剩余字节数：if remaining - 写入目标文件时，务必用
os.O_CREATE | os.O_WRONLY | os.O_TRUNC，避免旧文件残留内容干扰 - 示例片段：
chunkSize := int64(1024 * 1024) // 1MB
for offset := int64(0); ; offset += chunkSize {
if _, err := src.Seek(offset, io.SeekStart); err != nil {
break
}
dst, _ := os.OpenFile(fmt.Sprintf("part_%d", offset/chunkSize), os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)
n, err := io.CopyN(dst, src, chunkSize)
dst.Close()
if err == io.EOF || err == io.ErrUnexpectedEOF {
break
}
if n < chunkSize {
break // 实际读完
}
}按行边界切片（如日志/CSV）必须避开的坑
按行切片不是“每 N 行一分”，而是“确保每块以完整行为单位结尾”，否则下一块开头会丢半行数据。
典型错误是用 bufio.Scanner 直接循环读，它内部有缓冲且无法回退，切片位置不可控。
- 改用
bufio.NewReader+ReadBytes('\n')，读到换行符后手动计算当前块是否超限 - 若当前行加上已有内容会超限，就先写入当前块，再把这行作为下一块开头
- Windows 和 Unix 换行符不同（
\r\nvs\n），用strings.TrimRight(line, "\r\n")统一处理 - 最后一行无换行符的情况必须单独判断：
err == io.EOF && len(line) > 0
并发切片时文件句柄和偏移量怎么管
多个 goroutine 同时读同一个 *os.File 是安全的，但 Seek + Read 组合不是原子操作——两个 goroutine 可能 Seek 到同一位置然后重复读。
解决方法不是加锁整个文件，而是提前算好每个 goroutine 的起止偏移，各自打开独立句柄并 Seek 后只读自己那段。
- 用
os.Open多次打开同一文件，内核会复用底层 fd，开销可控 - 计算偏移时注意：第 i 块起始 =
i * chunkSize，结束 =min((i+1)*chunkSize, fileSize) - 写入目标文件名建议含序号（如
part_0001.bin），避免并发写冲突 - 别用
os.Create，它隐含O_TRUNC，万一某块失败重试会清空已写内容
真正麻烦的是按行切片的并发——行边界无法预估偏移，只能单线程扫描获取所有行首位置后再分段，或者接受少量跨块冗余（如每块多读 1KB 预热缓冲）。
