应使用流式计算避免内存溢出：用file.openread()配合md5.create().computehash()分块处理，不加载全文；sha256等算法调用方式一致，仅需替换类名；注意线程安全、文件锁定、路径权限及长度匹配。
用 MD5.Create() 计算大文件 MD5 容易卡死或爆内存
直接用 File.ReadAllBytes() 读整个文件再哈希，1GB 文件就可能让进程吃掉 2GB 内存（.NET 的 byte[] 是连续堆内存），还可能触发 GC 压力甚至 OutOfMemoryException。真正安全的做法是流式计算。
- 始终用
using var fs = File.OpenRead(path);打开只读流，避免文件句柄泄漏 - 传入
MD5.Create()的ComputeHash(Stream)方法，它内部自动分块读取（默认 4KB 缓冲） - 别自己写 while 循环 +
Read()——ComputeHash()已优化过，手动控制反而容易出错
using var md5 = MD5.Create();
using var fs = File.OpenRead("data.bin");
byte[] hash = md5.ComputeHash(fs); // 安全，不加载全文到内存
string hex = BitConverter.ToString(hash).Replace("-", "").ToLowerInvariant();
SHA256 和 MD5 在 System.Security.Cryptography 里调用方式完全一致
不是两个不同 API，只是换了个类名。所有哈希算法（SHA256、SHA512、MD5）都继承自 HashAlgorithm，ComputeHash(Stream) 接口一模一样。选哪个只取决于你校验方要求什么算法——MD5 已不推荐用于安全场景，但老系统还在用；SHA256 是当前通用底线。
- 替换时只需改类名：
SHA256.Create()→MD5.Create()，其余代码一行不用动 - 注意：
SHA256输出 32 字节（256 位），MD5是 16 字节（128 位），hex 字符串长度分别是 64 和 32，比对前确认长度是否匹配 - 不要混用：服务端返回 SHA256 校验值，客户端却算 MD5，结果永远不等
校验失败？先检查 FileStream 是否被其他程序占用或路径权限不足
常见错误不是哈希算错，而是根本没读到正确内容。比如文件正被记事本、Excel 或杀毒软件锁定，File.OpenRead() 会抛 IOException；或者路径含中文/空格但没做转义，导致打开的是空文件或报 FileNotFoundException。
- 加一层存在性检查：
if (!File.Exists(path)) throw new FileNotFoundException($"找不到文件: {path}"); - 捕获
IOException并提示“文件可能被其他程序占用”，比只显示“校验失败”有用得多 - 确保运行进程有读取该路径的权限（尤其在 Windows Server 或 Linux 上部署时）
多线程并发计算多个文件哈希时，每个线程必须新建自己的 MD5 实例
MD5 对象不是线程安全的。如果多个线程共用一个 MD5 实例（比如 static 字段缓存），会出现哈希值错乱，且极难复现——可能 99% 的时间正常，某次并发高峰就出错。
- 绝对不要写
private static readonly MD5 _md5 = MD5.Create(); - 每次计算都用
using var algo = MD5.Create();，.NET 会复用底层资源，开销可忽略 - 如果性能真成瓶颈（比如每秒算上千个小文件），考虑用
SHA256Cng（Windows）或SHA256Managed（跨平台），它们在某些场景下更快，但优先保证正确性
bin\ 目录），或者没处理好文件编码/换行符（文本文件用二进制模式读才准确）。哈希本身很可靠，问题几乎总出在“读”的环节。
