本文揭示了在 Jenkins 上运行 Maven JUnit 测试时 MessageDigest 生成哈希值与本地不一致的根本原因——文件资源重复读取导致流耗尽，并提供可复现的修复方案与最佳实践。
本文揭示了在 jenkins 上运行 maven junit 测试时 `messagedigest` 生成哈希值与本地不一致的根本原因——**文件资源重复读取导致流耗尽**，并提供可复现的修复方案与最佳实践。
在 Java 应用中使用 MessageDigest 计算文件哈希（如 MD5、SHA-256）是常见需求，但当该逻辑被封装进 Spring 的 ByteArrayResource 并用于单元测试时，一个隐蔽的陷阱极易引发跨环境行为差异：ByteArrayResource.getInputStream() 每次调用都会返回一个新的、可重置的 InputStream 实例——这看似安全，实则暗藏风险。
问题核心在于你的 hash() 方法实现：
public String hash(ByteArrayResource obj, String algorithm) throws NoSuchAlgorithmException {
Security.addProvider(new BouncyCastleProvider());
Security.addProvider(new GnuCrypto());
var md = MessageDigest.getInstance(algorithm);
try (DigestInputStream dis = new DigestInputStream(
new BufferedInputStream(obj.getInputStream()), md)) {
byte[] buffer = new byte[1024];
while (dis.read(buffer) != -1) ; // ⚠️ 关键：此处消耗流
byte[] hash = md.digest();
return DatatypeConverter.printHexBinary(hash).toUpperCase();
} catch (IOException e) {
throw new RuntimeException(e);
}
}表面看逻辑无误，但隐患来自测试用例本身：
void hashOk() {
byte[] bytes = Files.readAllBytes(Path.of("path/to/file.xml"));
String hash1 = "5EDF3285285FDABCFFB7019E2442B31F";
String hash2 = hashService.hash(new ByteArrayResource(bytes), "MD5"); // ✅ 正确：每次新建 ByteArrayResource
Assertions.assertEquals(hash1, hash2);
}⚠️ 真正的问题不在哈希算法或 Provider 注册，而在于测试中 ByteArrayResource 的生命周期管理。
你提到“把文件内容放在单行并改为只读一次”，这恰恰印证了问题本质：若测试类中 ByteArrayResource 被复用（例如作为类成员变量），或文件路径指向动态资源（如临时文件、classpath 资源），则多次调用 getInputStream() 可能因底层实现差异（尤其 Jenkins 的 JVM/ClassLoader/文件系统缓存策略）导致流内容不一致或提前 EOF。
更关键的是：DigestInputStream 在 read() 循环结束后，内部 MessageDigest 已完成计算；但若 obj.getInputStream() 返回的流在 DigestInputStream 构造前已被其他代码（如日志、断言辅助方法）意外读取过，则后续 DigestInputStream 将读到空流 → md.digest() 基于空输入计算 → 输出固定错误哈希（如你 Jenkins 中得到的 7A7E0BBA...）。
✅ 正确做法：确保输入流仅被消费一次，且资源创建与使用严格绑定
推荐重构方案（安全、可移植、符合测试最佳实践）：
// ✅ 改为直接接收 byte[]，彻底规避 InputStream 生命周期问题
public String hash(byte[] content, String algorithm) throws NoSuchAlgorithmException {
MessageDigest md = MessageDigest.getInstance(algorithm);
byte[] hash = md.digest(content); // 直接 digest 字节数组，零副作用
return DatatypeConverter.printHexBinary(hash).toUpperCase();
}
// 测试用例保持简洁明确
@Test
void hashOk() throws IOException {
byte[] fileBytes = Files.readAllBytes(Path.of("src/test/resources/test-file.xml"));
String expected = "5EDF3285285FDABCFFB7019E2442B31F";
String actual = hashService.hash(fileBytes, "MD5");
assertEquals(expected, actual);
}? 额外注意事项：
- 移除冗余 Provider 注册：BouncyCastleProvider 和 GnuCrypto 在 Java 11+ 中对标准算法（MD5/SHA-1/SHA-256）非必需，且重复 Security.addProvider() 可能干扰默认 Provider 优先级。如需扩展算法，应通过 Security.insertProviderAt() 并确保幂等性。
- 弃用 DatatypeConverter：该类已自 Java 9 起标记为 deprecated。改用 Hex.encodeHexString(hash).toUpperCase()（Apache Commons Codec）或 String.format("%02X", ...) 手动转换。
- Jenkins 环境验证：在 CI 中添加诊断日志，打印 fileBytes.length 和前 16 字节十六进制值，确认文件读取一致性。
总结：哈希不一致 rarely 是加密算法本身的问题，而是 I/O 资源管理的“幽灵 Bug”。坚持 “输入即确定”原则（输入字节数组而非可变流）、避免静态/共享资源复用、在测试中显式控制数据源，即可一劳永逸地消除 Jenkins 与本地的哈希差异。
