按内容特征切分大文件需基于数据结构（如时间戳、JSON边界、XML标签）而非固定字节/行数，Go中须用bufio.Scanner自定义SplitFunc实现流式安全切分，避免跨块截断记录。
按内容特征切分大文件，本质是放弃“固定字节”或“固定行数”的机械分割，转而依赖数据内部结构——比如日志中的时间戳、JSON 对象边界、XML 标签闭合、或自定义分隔符（如 ---\n）。Go 没有内置支持，必须手动扫描 + 回溯 + 边界对齐，否则极易切碎一条记录。
如何用 bufio.Scanner 安全识别自定义分隔符
bufio.Scanner 默认按 \n 切，但可通过 Split 方法注入自定义逻辑。关键不是“能切”，而是“不越界”：不能让一次 Scan() 返回跨块的不完整数据。
- 传入的
SplitFunc必须返回(advance int, token []byte, err error)，其中advance是从当前读取位置往前跳多少字节，token是本次提取的内容 - 若分隔符本身含多字节（如
"---\n"），需在缓冲区中滑动比对，不能只查单个字符；否则遇到"--\n---\n"会错判 - 缓冲区大小必须足够容纳最长可能的记录（例如含 base64 的 JSON 日志），否则
Scanner.Err() == bufio.ErrTooLong - 示例：识别以
"[INFO]开头的新日志条目，SplitFunc需向前回溯找上一个"[INFO]"起始位置，而非简单匹配字符串
为什么不能直接用 strings.Split 或 bytes.Index 全量加载后处理
因为这违背了“大文件”前提：os.ReadFile 会把整个文件读进内存，1GB 文件直接触发 OOM；strings.Split 还额外拷贝所有子串，放大压力。
- 正确路径是流式读取 + 环形缓冲区（ring buffer）或滚动窗口（sliding window）来捕获跨块的分隔符
- 例如处理 XML，需维护一个栈记录
<tag>和</tag>的嵌套深度，仅当深度归零时才视为一个完整文档 - 若用
bytes.Index在每次读取的[]byte中找"---\n"，但该分隔符被切在两块之间（前块末尾是"---"，后块开头是"\n"），就会漏识别 - 解决方案：保留上一块末尾最多 N 字节（N ≥ 分隔符长度），与下一块开头拼接后再搜索
如何保证每个分片以完整语义单元结尾（如闭合 JSON 对象）
JSON 不像日志有天然换行，一个对象可能横跨多个 10MB 块。强行按字节切会导致后续 json.Unmarshal 报 invalid character。
立即学习“go语言免费学习笔记（深入）”；
- 需实现状态机：逐字节解析，跟踪
{/[深度、字符串引号是否闭合、注释是否结束 - 不要依赖第三方 JSON 流解析器（如
jsoniter）自动跳过错误——它无法告诉你“这里该切”，只能告诉你“这里错了” - 更稳妥的做法：先用
file.Seek定位到粗略块边界，再向后扫描直到找到第一个完整对象结尾（即深度归零且非字符串内），将该位置设为分片终点 - 若扫描超时（如连续 1MB 未闭合），应报错退出，而不是无限等待——说明输入格式异常，不是切分逻辑问题
合并时最容易被忽略的边界情况
按内容切分后的合并，不只是顺序拼接。如果切点落在两个语义单元之间（如 }\n[INFO]），合并后可能多出空行或粘连；如果切点在单元内部（如 { "name": "a），则永远无法恢复。
- 每个分片文件末尾必须写入完整单元，不可截断；若最后一块无完整单元，应丢弃该块并告警，而非强行补全
- 合并脚本不能依赖
filepath.Glob("part_*")后sort.Strings——若分片名是part_2024-06-01.json、part_2024-06-02.json，字符串排序没问题；但若含part_v1.2.0、part_v1.10.0，就会错序 - 推荐在分片写入时，同时生成一个
manifest.json，明确记录每个分片的起始偏移、结束偏移、对应语义单元 ID（如日志时间范围、JSON ID 字段值），合并时按 manifest 顺序读取，而非文件名
