绝不能用 String.GetHashCode() 做内容聚类，因其哈希值跨版本/运行时不一致、碰撞率高、对 Unicode 敏感；应改用 SHA256 等确定性哈希，并统一归一化、编码探测与动态字段清洗。
用 String.GetHashCode() 做内容聚类？别这么干
它看起来快又简单，但哈希碰撞率高、跨进程不一致、对中文等 Unicode 字符敏感，同一段文本在不同 .NET 版本或不同运行时（.NET Framework vs .NET 5+）可能算出不同值。实际用于聚类，会导致同内容文档分到不同组，或者不同内容偶然撞出相同哈希——这不是 bug，是设计使然。
实操建议：
- 永远不用
String.GetHashCode()当唯一标识做聚类依据 - 如果只是去重，用
string.Equals()或StringComparer.Ordinal比较更稳妥 - 真要哈希，改用确定性算法，比如
SHA256计算内容摘要，再取前 8 字节转为 long 分桶
小文件用 File.ReadAllText() + SHA256 生成指纹
适合单个文件 ≤10MB、总量几百到几千份的场景。核心思路是把文件内容转成固定长度、抗碰撞的摘要，相同内容必得相同摘要，天然适合作为聚类 key。
常见错误现象：直接对原始文本做 GetHashCode() 或用 Encoding.UTF8.GetBytes() 后取前 N 字节——前者不稳定，后者忽略换行归一化、BOM、空格差异，导致“看起来一样”的文档被分错组。
实操建议：
- 读取前统一 Normalize：用
text = text.Replace("\r\n", "\n").Trim()消除换行差异 - 计算哈希前转为 UTF-8 字节数组，避免编码歧义：
SHA256.HashData(Encoding.UTF8.GetBytes(normalizedText)) - 为节省内存，可只取前 8 字节转
long当分组 ID：BitConverter.ToInt64(hash, 0)
大文件或海量文档必须流式处理 + 内容采样
读全量内容进内存会 OOM，尤其当有上百 MB 的日志或 XML 文件。这时不能依赖全文哈希，得靠特征提取：头部 + 尾部 + 关键词密度 + 结构标记（如 JSON 的字段名集合、XML 的根节点+属性名）。
性能影响明显：全文哈希 1000 个 5MB 文件约耗 3–5 秒；而采样法（取前 2KB + 后 2KB + 所有 "id" / "name" 出现次数）可压到 300ms 内，且准确率在文档结构相似时仍超 90%。
实操建议：
- 用
FileStream+StreamReader分段读，避免File.ReadAllText() - 对 JSON 文件，用
JsonDocument.Parse（不加载整棵树）提取RootElement.GetPropertyNames()并排序后拼接成 signature - 对纯文本，统计 top 5 非停用词（如 “error”, “config”, “user”）频次，拼成
"error:3;config:1;user:2"类字符串再哈希
聚类结果不稳定？检查是否忽略了文件元信息和编码探测
两个内容完全相同的文件，若一个是 UTF-8 with BOM、另一个是 UTF-8 no BOM，Encoding.UTF8.GetString() 会返回不同字符串——BOM 被当成了三个不可见字符。这会导致指纹不一致，聚类断裂。
容易被忽略的地方：
- 不要硬写
Encoding.UTF8，用File.ReadAllBytes()+EncodingDetector.DetectEncoding()（或Ude.CharsetDetector）先猜真实编码 - Windows 记事本保存的 ANSI 文件，在中文系统下其实是 GBK，直接用 UTF8 解会乱码，进而指纹全错
- 如果文档含时间戳、UUID、路径等动态字段，需正则预清洗：
Regex.Replace(text, @"(20\d{2}-\d{2}-\d{2}|\{[0-9a-f\-]{36}\})", "___DATE___")
真正难的不是算法，是让不同来源、不同编辑器、不同历史时期产生的文件，在“语义相同”时产出一致指纹。这一步没做稳，后面怎么调聚类算法都白搭。
