go中重复数据块检测本质是找完全一致的连续字节序列，应使用流式哈希（如io.readfull+hash.hash）按固定块大小计算哈希值，以[32]byte为key存map记录offset，末尾不足块需特殊处理，避免oom和误判。
Go 语言里做“重复数据块检测”，本质不是找相似内容，而是找**完全一致的连续字节序列**。如果你要的是模糊匹配或语义去重，dupl 或 AST 分析工具才合适；但若目标是识别相同内容的重复块（比如日志中反复出现的错误堆栈、配置模板拷贝、二进制 chunk），直接按块哈希比对最稳、最快。
用 io.Copy + hash.Hash 流式计算块哈希
别把整个文件读进内存再切块——大文件（>100MB）会 OOM。正确做法是打开文件后，用固定大小 buffer 循环读取，每读一块就喂给哈希器：
-
bufio.NewReader或直接io.ReadFull控制块大小（如 4KB、64KB，需对齐业务场景） - 每次读满一块后调用
hash.Write()，然后hash.Sum(nil)获取当前块哈希值 - 哈希值用
[32]byte（SHA256）或[16]byte（MD5）作 map key，value 记录首次出现的 offset - 遇到已存在的哈希值，说明该块重复；记录 offset 和长度，就能定位到具体位置
注意块边界与填充问题
真实文件不总是整除块大小，末尾不足一块时处理方式直接影响结果：
- 默认用
io.ReadFull会返回io.ErrUnexpectedEOF—— 这是正常信号，不是错误，要主动捕获并单独哈希剩余字节 - 如果业务要求“严格等长块”，末尾不足部分可丢弃，或补零（
bytes.Repeat([]byte{0}, n)），但必须和上游约定一致 - 文本文件慎用固定块：一行跨两个块会导致同一逻辑行被拆开哈希，误判为不同块；此时应改用“按行哈希”而非“按块哈希”
重复块判定后怎么输出？
光知道“有重复”不够，得能回溯到原始位置。建议结构体封装关键信息：
type BlockInfo struct {
Hash [32]byte
Offset int64
Size int
}
- 用
map[[32]byte][]BlockInfo存储每个哈希对应的全部出现位置 - 遍历 map，只保留
len(locations) > 1的项，即真正重复的块 - 输出时带上
Offset和Size，方便用dd if=file bs=1 skip=$offset count=$size验证
为什么不用 slices.Contains 或嵌套循环比对块？
这是最容易踩的坑：块数量一多，O(n²) 就卡死。假设一个 1GB 文件按 64KB 切块，约 16384 块；两两比对要接近 1.3 亿次 memcmp —— 实测在 SSD 上也要数秒，且无法扩展。
-
slices.Contains是线性查找，每次都要扫前面所有块，完全不可行 - 哪怕只做“是否存在”，也必须用哈希表（
map[[32]byte]bool）做 O(1) 查找 - 如果块很大（如几 MB），memcmp 开销本身也高，哈希一次反而更快
真正麻烦的不是哈希算法选型，而是块边界对齐、EOF 处理、以及哈希值在不同平台/工具间是否可复现——这些细节漏掉一个，重复块就可能漏报或误报。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
