Java中MessageDigest线程不安全，须每次调用getInstance获取新实例；字符串转字节需显式指定UTF-8编码；SHA-256支持硬件加速；算法名须全大写如"SHA-256"。
Java里用MessageDigest算MD5或SHA-256，别直接new Digest对象
Java标准库的MessageDigest是线程不安全的，每次都要调用MessageDigest.getInstance("MD5")或MessageDigest.getInstance("SHA-256")获取新实例，不能缓存复用。常见错误是把MessageDigest做成单例或静态字段，结果多线程下输出错乱、摘要值偶尔对不上。
实操建议：
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 每次计算都走
getInstance，哪怕看起来“浪费”，这是最稳的做法 - 如果性能真成瓶颈（比如每秒上万次小字符串哈希），再考虑
ThreadLocal<MessageDigest>，但务必在remove()前调用reset() - 别用
Security.addProvider(...)强行替换底层实现，除非你清楚JCE策略文件和FIPS模式的影响
输入字节数组还是字符串？编码不指定就踩坑
MessageDigest只认byte[]，但多数人传的是字符串。如果直接调str.getBytes()，会用平台默认编码（Windows是GBK，Linux/macOS通常是UTF-8），同一段文字在不同机器上算出的MD5/SHA-256完全不同。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远显式指定编码：
str.getBytes(StandardCharsets.UTF_8) - 如果处理的是文件内容，别用
Files.readString再转字节——直接Files.readAllBytes(path)，避免二次编码 - Base64或Hex编码结果时，用
DatatypeConverter.printHexBinary(digest)（旧）或HexFormat.of().formatHex(digest)（Java 17+），别手写字符拼接
SHA-256比MD5慢多少？不是关键瓶颈，但别在循环里反复调用getInstance
单次计算耗时：MD5约0.1μs，SHA-256约0.3–0.5μs（Intel i7，HotSpot JIT后）。差距存在，但远小于IO或GC开销。真正拖慢的往往是误用方式——比如在for循环里每轮都调一次getInstance("SHA-256")，触发重复类加载和算法初始化。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把
getInstance提到循环外，但记得每次循环内必须调digest.reset()（或新建实例） - 如果要连续哈希多个数据块（如大文件分片），用
update(byte[])多次，最后digest()一次出结果，别拆成多次digest() - JDK 8u231+起，
SHA-256已支持硬件加速（Intel SHA extensions），无需额外配置，但OpenJ9或某些ARM JDK可能不启用
遇到NoSuchAlgorithmException？检查算法名大小写和JDK版本
报错java.security.NoSuchAlgorithmException: MD5 Instance not available通常不是算法缺失，而是拼写错误或环境限制。JDK所有版本都内置MD5/SHA-1/SHA-256/SHA-512，但算法名必须全大写、无空格、无连字符。
常见错误现象：
- 写成
"md5"或"Md5"→ 正确是"MD5" - 写成
"SHA256"或"sha-256"→ 正确是"SHA-256" - 在FIPS合规模式下运行（如
-Djavax.net.ssl.trustStoreType=JKS配合FIPS provider），MD5被禁用 → 改用"SHA-256" - Android低版本（API SHA-3等新算法支持不全，但MD5/SHA-256始终可用
最常被忽略的一点：MessageDigest计算结果是原始字节数组，直接toString()得到的是对象地址，不是哈希值。必须转Hex或Base64——这个错，上线后查日志能看半小时才反应过来。
