按行分割大文件需保证行边界完整，应先按字节粗略分块，再回溯找换行符对齐；不可直接用bufio.Scanner循环读写，因其不可回退且效率低；二进制文件应改用字节切分并校验。
大文件按行分割不是“切字节”，而是要保语义——行边界不能断在中间，否则后续解析会出错。Go 本身没有内置的“按行 split”函数，bufio.Scanner 是最常用入口，但直接用它分片会丢数据、卡死或内存暴涨，必须配合 os.File.Seek 手动控制指针。
为什么不能直接用 bufio.Scanner 循环读 + 写新文件？
因为 bufio.Scanner 是单向流式读取器，一旦调用 Scan()，内部缓冲区前移、文件指针不可回退。你想把第 100 万行开始的 10 万行写进 part_02，就得从头再扫一遍——O(N²) 时间，且无法并行预估偏移量。
- 每次重开
Scanner都得重新打开文件，系统 fd 耗尽风险上升 - 大日志文件（如 5GB nginx access.log）反复 seek + scan 极慢
-
Scanner默认缓冲区 64KB，遇到超长行（比如含 base64 的 JSON 日志）直接 panic
正确做法：用 os.File.Seek 定位行首 + io.ReadBytes('\n') 精确截断
核心思路是：先粗略按字节把文件切成等长块（比如每块 10MB），再在每个块末尾向前搜索最近的 '\n'，把该位置设为下一块起点。这样既避免全量扫描，又保证每块以完整行为界。
- 用
file.Stat().Size()获取总长度，计算块数：numParts := int(math.Ceil(float64(total) / float64(chunkBytes))) - 对第
i块，起始偏移 =i * chunkBytes；但需用file.Seek(start, 0)后调file.Read([]byte{0})检查是否正好落在行首 —— 若不是，就Seek(-1, 1)往回找'\n' - 找到行首后，用
io.ReadBytes('\n')或循环file.Read()直到读到换行符，确保不切碎一行 - 每个分片文件用
os.Create(fmt.Sprintf("part_%03d.log", i))创建，零填充命名防排序错乱
遇到二进制文件或无换行符的场景怎么办？
按行分割的前提是「目标文件有明确行结构」。如果处理的是视频、PDF、加密 blob 等二进制文件，强行按 '\n' 切只会损坏数据 —— 这时应退回到纯字节切分，用 io.CopyN。
立即学习“go语言免费学习笔记（深入）”；
- 确认输入是否真为文本：可用
file.ReadAt([]byte{0}, 0)读首字节，检查是否在 ASCII 可见字符范围（0x20–0x7E）或 UTF-8 合法头 - 若不确定，宁可放弃“按行”，改用固定字节切分 + 零填充命名 + SHA256 校验，这是最稳的 fallback
- 不要混合策略：比如“前 100MB 按行，后面按字节”——合并时逻辑断裂，没人能维护
合并时最容易被忽略的三个细节
合并不是简单 cat，尤其当分片由不同机器上传后再下载时，顺序、权限、结尾换行都可能出问题。
- 必须用
filepath.Glob("part_*.log")+sort.Slice(files, func(i, j int) bool { return extractNum(files[i]) 提取序号排序，不能信 <code>ls或range遍历顺序 - 每个分片
os.Open后，用io.Copy(merged, part)追加，别用os.OpenFile(..., os.O_APPEND)—— 多次打开同一文件在某些 NFS 上会丢写入 - 原始文件末尾若无换行符，最后一个分片末尾也不该多加一个 —— 否则 diff 失败。可在分割时记录最后一块是否以
'\n'结尾，合并时按需补
按行分割的本质是「在字节流里做语义对齐」，而 Go 的 os.File 和 io 包只管字节。所有“行”的逻辑都得自己守，包括找边界、容错、校验。跳过这层理解，直接套 Scanner 示例代码，十次有九次会在 2GB 日志上静默失败。
