java校验大文件完整性需三点：确保数据落盘（用close()或force(true)）、流式分块计算哈希（如digestutils）、传输中用crc32校验字节一致性，哈希比对前统一小写十六进制格式。
Java 中校验大文件完整性与传输一致性，关键在三点：确保数据真正落盘、流式分块计算哈希或校验值、两端字节序列严格一致。不是比谁算得快，而是比谁不丢字节、不抢时机、不错格式。
先等文件写完再校验
很多“校验失败”其实不是算法出错，而是文件还没真正写入磁盘就急着算哈希。OutputStream 的 write() 返回不代表数据已落盘，尤其在 NFS、USB 设备或低端 SSD 上更明显。
- 写入后显式调用 flush() + getChannel().force(true) 强制同步
- 更稳妥的做法是用 try-with-resources 自动关闭流——close() 会隐式触发 flush 和 fsync
- 避免“写完立刻算”，加个简单判断：比如检查文件长度是否稳定、或用 Files.getLastModifiedTime() 辅助确认
用流式分块计算哈希（MD5/SHA-256）
几 GB 文件不能全读进内存，否则极易 OOM。必须边读边更新哈希，全程零缓存全文。
- 用 FileInputStream 配合固定 buffer（如 8192 字节），循环 read()，每次调用 md.update(buffer, 0, bytesRead)
- 禁用 Files.readAllBytes() 或 Files.readString() —— 这些方法会把整个文件加载到堆内存
- 推荐 Apache Commons Codec 的 DigestUtils.md5Hex(file) 或 sha256Hex(file)：内部已做流式处理、异常封装和资源管理，10GB 文件在 SSD 上约 25–35 秒
传输中用 CRC32/Adler32 做轻量级流校验
适合 HTTP 下载、Socket 通信、日志归档等需低开销、高吞吐的场景。核心是发送端算、接收端复核，且两端 feed 的原始字节必须完全一致。
- 网络传输：服务端把响应体喂给 CRC32，把 getValue() 结果放入响应头（如 X-Checksum: crc32=ec4ac3d0）；客户端边读流边 update，读完对比
- 文件落盘：用 CheckedOutputStream 包裹 FileOutputStream，校验器自动随写入更新，写完直接取 crc.getValue() 存为元数据
- CRC32 抗随机错误更强，Adler32 计算更快（尤其长数据），但检错能力略弱——对普通传输选 CRC32 更稳妥
哈希值比对前统一格式
“明明一样却判不同”，八成是大小写或位数不一致。MD5 必须是小写 32 位十六进制，SHA-256 必须是小写 64 位。
- 生成时用 String.format("%02x", b) 拼接每个字节，或 JDK 17+ 直接用 HexFormat.of().formatHex(digest)
- 比对前把预期哈希值也转为小写，并去掉空格、换行、前后缀（如 sha256=... 中的前缀）
- 不建议用 Base64 等其他编码，除非两端明确约定且严格统一
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
