分治去重需先确认数据可切分且去重粒度为行或固定分隔符；强行按字节切分超长单行JSON会破坏语义，导致误判或漏删；必须确保每块以完整行为边界，避免跨行截断，并通过行号或偏移量保序。
分治去重不是万能的，先看数据特征再决定是否并行
超大字符串文本（比如几 GB 的日志拼接体）直接用 map[string]struct{} 一次性加载去重，大概率 OOM。分治法能缓解内存压力，但前提是：文本可切分、去重粒度是行或固定分隔符单元、各子块间无强依赖。如果原始数据是单行超长 JSON 或嵌套结构，强行按字节切分会破坏语义，反而引入错误重复或漏删。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认去重单位：通常是
\n分隔的行，或自定义分隔符（如"|"），避免按字节/ rune 切分 - 预估总行数：用
bufio.Scanner遍历一次统计行数，再决定分块大小（例如每块 100 万行） - 不推荐对
string本身做分治——Go 中 string 是只读底层数组，切片不会复制，但并发读没问题；真正要分的是“逻辑记录流”
用 sync.Map 还是 map + sync.RWMutex？
分治后多个 goroutine 同时写入全局去重结果，必须线程安全。但 sync.Map 在高写入低读取场景（如纯去重累加）性能反而比带锁的 map 差，尤其 Go 1.21+ 后 map 并发写 panic 更明确，反而利于早期发现问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
map[string]struct{}+sync.RWMutex，读多写少时RWMutex优势明显；去重过程主要是写，但最终遍历输出是一次性读，所以写锁足够 - 避免在每个 goroutine 里新建
sync.Map再合并——合并成本高，且sync.Map.Range无法原子获取全部 key - 若去重后只需计数，用
atomic.Int64计数器 +map做存在判断，减少锁竞争
分块读取时如何避免跨行截断？
按固定字节数切文件，很容易把一行从中间劈开，导致某行被拆成两段分别进入不同块，造成误判重复或丢失。这是最常踩的坑。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
bufio.NewReader+ 自定义分块函数：先定位到最近的\n（向前搜索），确保每块以完整行为边界 - 示例关键逻辑：
for offset < fileSize { end := min(offset+chunkSize, fileSize) // 向前找 \n for end > offset && data[end-1] != '\n' { end-- } if end == offset { /* 单行超长，强制截断并告警 */ } go processChunk(data[offset:end]) offset = end } - 不要依赖
strings.Split全量加载后再切分——这一步就已爆内存
去重结果顺序怎么保？分治天然不保序
分治 + 并行处理后，结果顺序完全取决于 goroutine 完成时间，和原始顺序无关。如果业务要求输出保持首现顺序（即第一次出现的位置顺序），不能靠分治后简单合并 map keys。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 为每个逻辑块编号，并在处理时记录每行首次出现的绝对偏移（或行号），最后按偏移排序输出
- 更轻量做法：主 goroutine 按顺序发起分块任务，用
chan接收结果（chan []string），但需注意 channel 缓冲区大小，否则阻塞拖慢整体速度 - 如果只要去重不要序，最终用
for k := range resultMap遍历即可，无需额外排序
分治去重真正的复杂点不在并发控制，而在边界对齐和语义完整性——多线程读同一文件时，seek 位置、换行符识别、UTF-8 多字节字符截断，任何一个细节没对齐，结果就不可信。宁可慢一点做精确切分，也不要为省几毫秒引入静默错误。
