map[string]struct{}是单机内存去重最常用方案，适合日增百万级以下数据；超千万级需布隆过滤器+二次校验；百亿数据用哈希分治；并发写须隔离。
用 map[string]struct{} 做单机内存去重最常用，但有明确容量边界
Go 没有内置去重函数，map[string]struct{} 是标准库外最直接、可读性好、性能可控的方案。它利用哈希表 O(1) 查找特性，适合日增百万级以下的数据量（比如 API 返回的 ID 列表、日志行、URL 集合）。
常见错误包括：
- 用
map[string]bool——每个bool占 1 字节，而struct{}占 0 字节，千万级 key 差出几 MB 到上百 MB 内存 - 对结构体直接当 key：
map[MyStruct]struct{}编译失败，报invalid map key type，因为结构体含[]string、map[string]int或func()就不可比较 - 忘记初始化：
seen := make(map[string]struct{})缺失这行，运行时 panic
若元素是结构体，必须确保所有字段都可比较；否则得手动构造唯一键，比如 s.ID + "|" + s.Status，别用 fmt.Sprintf("%v", s) —— 输出格式不稳定，不同 Go 版本可能变化。
超千万级数据必须换布隆过滤器 + 二次校验
当缓存中要存上亿个 URL 或用户 ID，map 占用内存会暴涨（例如 1 亿个字符串，平均 32 字节/key，仅 key 就占 3.2 GB），这时硬扛会导致 GC 压力大、响应延迟高，甚至 OOM。
正确做法是用布隆过滤器做前置过滤：
-
bloom.Test()返回false→ 一定不存在，直接丢弃 -
bloom.Test()返回true→ 可能存在，必须走后端存储（如 RedisSET或 DBSELECT）确认是否真重复 - 初始化不能拍脑袋：
bloom.New(10_000_000, 0.001)表示预估存 1000 万条、容忍 0.1% 误判；设小了误判率飙升，设大了浪费内存 - 它不支持删除 —— 如果业务需要“撤回某条记录”，布隆过滤器完全无能为力，必须依赖后端存储兜底
100GB 级文件去重只能靠分治法，哈希取模是关键
面试或真实 ETL 场景中，遇到 100 亿 URL、内存只有 4GB，就不能全读进内存。核心思路是“把大问题拆成小问题，且保证相同元素进同一个桶”。
具体步骤：
- 遍历原始文件，对每行算
hash(line) % N（比如 N=100），写入file_0到file_99 - 因为哈希函数确定性，相同 URL 必进同一小文件；不同 URL 可能碰撞，但不影响最终去重正确性
- 逐个读小文件进内存，用
map[string]struct{}去重并输出 - 若某小文件仍超内存（比如
file_0被塞了 15GB），说明数据倾斜严重，需对该文件换另一个哈希函数递归拆分
注意：别用 sort + 双指针 替代——它要求先排序，而 100GB 文件无法在内存排序，外部排序开销远高于分治。
并发写 map 必 panic，多 goroutine 场景必须隔离写操作
多个 goroutine 同时往同一个 map 写，不出几秒就触发 fatal error: concurrent map writes。这不是概率问题，是确定性崩溃。
安全做法只有三种：
- 单 goroutine 收集：各数据源通过
chan []T发结果，由一个中心 goroutine 统一建map去重（推荐，逻辑清晰、易调试） - 分片 map：按 key 哈希取模分到 N 个本地
map，最后合并；适合大数据量且 key 分布均匀 -
sync.Map：仅当 key 是string/uint64等简单类型、且读远多于写时才考虑；但它不支持遍历全部 key，想拿到最终去重列表还得额外维护 slice
路径类、URL 类数据还容易忽略归一化：比如 /api/user/123 和 /api/user/456 应模板化为 /api/user/{:id} 再去重，否则语义重复却判定为不同。
