说实话，看到“SHA加密算法”这个标题，我第一反应是：这又是一个被写烂的入门Demo。但实际在项目里接手过几个跟数据校验、安全存储相关的模块之后，我觉得“SHA”这一块值得聊的东西其实非常多——很多人止步于会用MessageDigest.getInstance("SHA-256")算个哈希，但真正到了生产环境，选哪个变体、怎么处理编码、文件流要怎么读、加了盐之后为什么还是不够，这些问题如果不提前想清楚，后面返工的成本会很高。
这篇文章我不打算堆叠官方文档那套说法，而是从实际开发的角度，把这几年做Java后端时跟SHA打交道踩过的坑、沉淀下来的经验一次讲透。内容包括SHA家族的整体选型思路、MessageDigest的核心机制、字符串与文件场景的完整代码实现、加盐和HMAC的实际用法，以及一张可以直接收藏的常见问题排查表。不管你是刚接触摘要算法的新手，还是已经写过几版工具类但想确认有没有写错的老手，这篇文章应该都能帮你省下一点试错时间。
1. 先想清楚算法选型，再写第一行代码
很多人一上来就写SHA-256，这本身没错，但你要知道自己为什么选它。SHA这个家族里头，SHA-1、SHA-256、SHA-512是三种完全不同的安全水位，选错了场景，轻则被安全评审打回，重则给线上系统埋雷。
1.1 为什么默认方案通常是SHA-256
SHA-1输出160位（20字节）的哈希值，在2005年就已经被理论碰撞攻击攻破，2017年谷歌和一家安全机构联合制造了真实的SHA-1碰撞实例。所以只要你的系统跟“对抗恶意输入”沾边，就不该再用SHA-1。SHA-256输出256位（32字节），目前没有实际可行的碰撞攻击，而且计算性能相当好，无论是纯软件实现还是硬件加速，它都是性价比最高的选择。SHA-512虽然更长，但在64位处理器上，它的计算速度甚至可能比SHA-256更快，因为SHA-512使用64位字长、更大的消息块和轮数结构。不过SHA-512的摘要长度是64字节，比SHA-256长一倍，存储和传输开销也随之变大。
这里给大家一个实际表格，把SHA家族里的主流变体摆在一起，平时选型对照着看就行。
| 算法 | 输出长度（位/字节） | 内部结构 | 安全状态 | 典型场景 |
|---|---|---|---|---|
| SHA-1 | 160 / 20 | Merkle-Damgård | 已实际碰撞，不可用于安全场景 | 仅兼容旧系统、数据去重 |
| SHA-224 | 224 / 28 | Merkle-Damgård | 安全但较少使用 | 需要更短摘要时折中 |
| SHA-256 | 256 / 32 | Merkle-Damgård | 安全，主流默认 | 文件校验、消息摘要、数字签名 |
| SHA-384 | 384 / 48 | Merkle-Damgård | 安全，阶数更高 | 兼容性要求较高的协议 |
| SHA-512 | 512 / 64 | Merkle-Damgård | 安全，64位平台性能好 | 高安全要求的存储 |
| SHA-3 | 可变 | Keccak海绵结构 | 安全，结构与SHA-2完全不同 | 新型系统、需要算法多样化时 |
1.2 JDK自带的摘要算法全家桶
Java的java.security.MessageDigest从JDK 1.1开始就是标准API了，你在生产环境里几乎不需要额外引第三方库就能完成99%的SHA需求。JDK根据运行平台的不同，底层会通过SPI机制选择一个可用的安全提供者，大多数情况下是SUN或SunJCE，这些提供者原生支持：SHA-1、SHA-224、SHA-256、SHA-384、SHA-512、SHA3-224、SHA3-256、SHA3-384、SHA3-512。
有个容易忽略的点是，算法名称字符串是大小写不敏感的，但推荐严格写成标准的连字符大写形式，比如"SHA-256"，因为某些第三方安全提供者（比如一些硬件加密模块）对算法名的解析可能比较严格。
注意：
MessageDigest不是线程安全的。同一个实例在多线程环境下调用digest()方法会导致结果错乱甚至抛出异常。正确的做法是每个线程单独创建实例，或者用ThreadLocal<MessageDigest>去做线程级缓存。
1.3 选型时容易踩的认知误区
第一个误区是觉得SHA-512一定比SHA-256安全一倍。哈希安全性取决于抗碰撞能力的位长，256位和512位的差距确实存在，但SHA-512的膨胀也带来了两倍存储开销，而SHA-256在当前算力下的安全性对绝大多数业务场景已经绰绰有余。除非是安全等级要求极高的政务、金融核心链路，或者需要通过算法套件多样化来满足合规要求，否则没必要为了“看起来更安全”去选SHA-512。
第二个误区是把SHA加密挂在嘴边。严格来说，SHA是摘要算法，不是加密算法。加密是可逆的，摘要不可逆。这个概念要是跟产品经理或安全评审解释不清楚，后面往往会被要求“把哈希解开”，你没法解，这就是需求理解层面的问题。你可以在团队内部文档里统一把它叫“哈希/摘要算法”，避免歧义。
2. 动手之前先吃透MessageDigest核心机制
我见过不少同事写哈希工具类时，代码能跑但总有一种“临时拼凑”感，比如每次循环都重新getInstance一次，或者干脆把digest(byte[])和toString()混在一起用。想要写出稳、快、不出问题的代码，得先理解MessageDigest的生命周期和使用机制。
2.1 初始化、更新与一次性结算
MessageDigest使用起来是个三段式流程：getInstance创建实例，update喂数据，digest结算结果。核心设计意图是支持流式数据的增量哈希——你不需要一次性把所有数据加载进内存，可以分批把数据块通过update(byte[], int, int)喂进去，最后统一digest()得到完整摘要。
MessageDigest digest = MessageDigest.getInstance("SHA-256"); digest.update("Hello, ".getBytes(StandardCharsets.UTF_8)); digest.update("World!".getBytes(StandardCharsets.UTF_8)); byte[] hash = digest.digest();这个例子看起来简单，但注意digest()在执行时做两件事：一是把已经喂进来的所有数据做最终填充和摘要计算，二是同时重置内部状态。也就是说，digest()之后这个实例不需要重新创建就能再次使用，但如果你在digest()之后继续update()，那是在一个重置后的新上下文中追加数据，结果跟连续一次性输入是不等价的。所以实践上我建议：一个实例结算完之后，尤其是单线程场景下，最保险的做法是直接重新getInstance，避免状态心智负担。
2.2 为什么JDK有现成的摘要计算方法，还要自己处理Hex编码
digest()返回的是byte[]，也就是原始二进制摘要。很多初学者直接对这个字节数组做toString()，得到一个类似[B@1b6d3586的对象地址，然后一脸懵。这是因为Java字节数组没有重写toString()，你要的是可读的十六进制字符串，JDK标准库并没有直接提供byte[] -> Hex的便捷方法（直到较新的JDK版本也仍然没有，但HexFormat在JDK 17之后出现了）。
所以实际开发里需要自己写一个Hex转换，或者用现成的库。我推荐在项目里统一封装，下面这段是稳定高效的写法，用了查表法，比逐字节拼接String.format("%02x")快得多：
private static final char[] HEX_ARRAY = "0123456789abcdef".toCharArray(); public static String bytesToHex(byte[] bytes) { char[] hexChars = new char[bytes.length * 2]; for (int i = 0; i < bytes.length; i++) { int v = bytes[i] & 0xFF; hexChars[i * 2] = HEX_ARRAY[v >>> 4]; hexChars[i * 2 + 1] = HEX_ARRAY[v & 0x0F]; } return new String(hexChars); }这里有一个要点：bytes[i] & 0xFF这一操作，目的是把有符号的byte转成无符号的0到255范围，因为Java的byte是带符号的，负数的二进制表示在转十六进制时如果不做掩码处理，会得到ffffffff这样的错误结果。这个细节是哈希工具类最常见的Bug点之一。
2.3 开发中必须明确的三个编码细节
第一个细节是字符串编码。同一个字符串用getBytes()（平台默认字符集）和getBytes(StandardCharsets.UTF_8)去计算哈希，结果可能是不同的。在中文Windows环境下，默认字符集是GBK；在Linux服务器上，默认字符集通常是UTF-8。你本地算出来的哈希，到了服务器上对不上，先查这里。
// 推荐：显式指定字符集 byte[] input = text.getBytes(StandardCharsets.UTF_8);第二个细节是大小写。十六进制字符串输出时用大写还是小写，本身不影响哈希的“值”，但会影响对比的一致性。如果你跟外部系统对接，必须先确认对方用的是大写还是小写。建议项目内部统一用小写，因为小写十六进制在URL、文件名、数据库索引中更常见，也避免了很多不必要的大小写转换。
第三个细节是Base64与Hex的选择。同样的32字节摘要，Base64表达为43个字符左右，Hex表达为64个字符。如果你要存数据库或传输，Base64更省空间，但可读性差；如果要给人看、打日志、做文件名，Hex更好。我在做文件完整性校验时习惯用Hex，在把哈希值塞进消息头或Token里时则用Base64。没有绝对标准，但一定要统一。
3. 完整实操：从字符串哈希扩展到文件校验与批量计算
理论说再多，不如直接把能用的代码贴出来。这一节我会从最常用的字符串哈希工具类写起，然后处理大文件校验时的内存优化问题，再补上批量计算和HMAC的进阶写法。
3.1 单字符串SHA-256工具类，五段代码写完
下面的工具类封装了最核心的流程：获取实例、喂入字节、转Hex、输出。生产环境里我一般还会增加一个静态工厂方法，允许调用方传入算法名，这样想从SHA-256切换到SHA-512时不用改调用方代码。
import java.nio.charset.StandardCharsets; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; public final class ShaUtils { private ShaUtils() {} public static String sha256Hex(String text) { return hashHex("SHA-256", text.getBytes(StandardCharsets.UTF_8)); } public static String hashHex(String algorithm, byte[] data) { try { MessageDigest digest = MessageDigest.getInstance(algorithm); byte[] hash = digest.digest(data); return bytesToHex(hash); } catch (NoSuchAlgorithmException e) { throw new IllegalArgumentException("Unsupported algorithm: " + algorithm, e); } } private static final char[] HEX_ARRAY = "0123456789abcdef".toCharArray(); public static String bytesToHex(byte[] bytes) { char[] hexChars = new char[bytes.length * 2]; for (int i = 0; i < bytes.length; i++) { int v = bytes[i] & 0xFF; hexChars[i * 2] = HEX_ARRAY[v >>> 4]; hexChars[i * 2 + 1] = HEX_ARRAY[v & 0x0F]; } return new String(hexChars); } }这段代码看起来简单，但已经考虑了三个问题：一是捕获了NoSuchAlgorithmException并转成了运行时异常，调用方不会被强制try-catch烦扰；二是显式使用UTF-8编码，消除跨平台乱码；三是Hex转换用查表法，性能比String.format高出一个量级。实测在普通笔记本上，这段代码计算一万次短字符串SHA-256耗时在几十毫秒级别，完全够用。
3.2 大文件哈希校验怎么优化内存
计算文件SHA-256有一个非常经典的坑：直接用Files.readAllBytes()把整个文件读进内存再哈希。这在几十MB的小文件上没问题，但一旦文件到了几个GB，内存就爆了。正确的姿势是开一个缓冲区循环读文件块，每读一块就update一次，最后digest。
public static String sha256File(File file) throws IOException { try (InputStream in = new BufferedInputStream(new FileInputStream(file))) { MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] buffer = new byte[8192]; int len; while ((len = in.read(buffer)) != -1) { digest.update(buffer, 0, len); } return bytesToHex(digest.digest()); } catch (NoSuchAlgorithmException e) { throw new IllegalStateException("SHA-256 algorithm not available", e); } }缓冲区大小选8192字节是基于常见磁盘块大小和JVM默认IO缓冲折算出来的。你可以试着调成16KB或64KB，在某些文件系统上吞吐会更好，但8192是实测稳定且内存占用优雅的组合。这里有一个进阶优化点：update(buffer, 0, len)比update(buffer)更安全，因为最后一次read返回的字节数可能小于缓冲区长度，如果直接update(buffer)，会把上次遗留的无用数据也计算进去。
重要提示：文件哈希建议配合CRC32或文件大小一起使用。SHA-256只能确保内容一致，如果文件元数据（比如文件名、修改时间）也需要校验，那些数据不属于文件字节内容，需要单独处理。
3.3 批量计算时的并发处理和开销分析
批量哈希的场景常见于数据同步、重命名去重或者构建增量索引。一次处理几万个字符串时，如果循环里每次都重新getInstance，JVM创建对象的开销和GC压力会明显上升。我的做法是，根据CPU核数开一个固定大小线程池，用ThreadLocal缓存MessageDigest实例。
private static final ThreadLocal<MessageDigest> DIGEST_HOLDER = ThreadLocal.withInitial(() -> { try { return MessageDigest.getInstance("SHA-256"); } catch (NoSuchAlgorithmException e) { throw new IllegalStateException(e); } }); public static String sha256Concurrent(String text) { MessageDigest digest = DIGEST_HOLDER.get(); digest.reset(); byte[] hash = digest.digest(text.getBytes(StandardCharsets.UTF_8)); return bytesToHex(hash); }注意这里我在使用前主动调了reset()，目的就是防止上一个任务留下的内部状态污染当前结果。ThreadLocal加上reset()的组合，既消灭了并发问题，又避免了频繁创建实例。实测在四核机器上处理100万次短字符串哈希，这个写法比同步单线程快3倍左右。
不过要提醒你：如果每个数据体量很小，批量计算的瓶颈往往不在CPU而在对象创建和IO上。不要盲目上多线程，先用单线程测一下耗时分布，确认CPU密集后再做并发优化，否则只是为了“看起来高性能”而陷入过度设计。
3.4 用HMAC-SHA256解决密钥参与摘要的问题
有时候你需要算的不是简单的哈希，而是带密钥的摘要，典型场景是API签名、Webhook回调验签。直接SHA-256(secret + data)有长度扩展攻击等隐患，正确的做法是用HMAC。JDK里Mac类支持HmacSHA256，用法跟MessageDigest非常像，只是初始化时需要传入SecretKeySpec。
import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import java.nio.charset.StandardCharsets; public static String hmacSha256Hex(String data, String secretKey) { try { Mac mac = Mac.getInstance("HmacSHA256"); SecretKeySpec keySpec = new SecretKeySpec( secretKey.getBytes(StandardCharsets.UTF_8), "HmacSHA256"); mac.init(keySpec); byte[] rawHmac = mac.doFinal(data.getBytes(StandardCharsets.UTF_8)); return bytesToHex(rawHmac); } catch (Exception e) { throw new IllegalStateException("HMAC computation failed", e); } }这段代码里SecretKeySpec的第二个参数必须是"HmacSHA256"，它告诉JVM这是一把用于HMAC-SHA256的密钥。密钥本身的长度建议至少32字节（256位），如果密钥太短，虽然算法不会报错，但抗暴力破解能力会下降。另外注意，HMAC的密钥是敏感数据，不要在日志里打印，也不要在代码仓库里写死明文密钥，要放到配置中心或环境变量里管理。
4. 说“安全”之前得先明白：SHA解决什么问题，不解决什么问题
既然标题里有“加密”两个字，我觉得有必要把安全的边界讲透。SHA是一个很基础的密码学原语，它本身不“加密”任何东西，也不保证“安全”。你在项目里到底该怎么用它，取决于你面对的是哪种威胁模型。
4.1 密码存储：只用SHA是典型的反面教材
我在代码评审时看到太多类似的实现：注册的时候把密码sha256Hex(password)存进数据库，登录的时候再算一次比对。这种方案在安全测试面前不堪一击——因为你没有加盐，同一个密码在所有系统里都得到同一个哈希值。攻击者拿到数据库后，只需要用彩虹表（预先算好的海量密码哈希表）一匹配，弱密码立刻原形毕露。
正确做法是给每个用户生成独立的随机盐（至少16字节），然后把盐 + 密码的哈希结果存下来。更稳妥的做法是使用专门的慢哈希算法，比如PBKDF2、bcrypt、scrypt或Argon2，这些算法通过迭代计算加大暴力破解的成本。Java标准库自带PBKDF2，实现一个加盐密码哈希其实并不复杂。
// 生成带盐的PBKDF2哈希，比单纯SHA-256更适合密码存储 public static byte[] pbkdf2(char[] password, byte[] salt, int iterations, int keyLength) throws Exception { PBEKeySpec spec = new PBEKeySpec(password, salt, iterations, keyLength); SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"); return factory.generateSecret(spec).getEncoded(); }如果你在维护一个旧系统，密码已经是普通SHA-256了，也不建议立刻全量重算，因为用户不会告诉你明文密码。通常的做法是：在登录验证逻辑里，如果发现当前用户还是旧的哈希方案，用输入的明文做一次升级，算出新的加盐哈希再覆盖旧值。这叫做“渐进式哈希迁移”。
4.2 文件完整性校验与发布校验的差异
文件下载站的SHA-256校验值，跟你在数据同步系统里算文件哈希，目的完全不同。前者对抗的是“下载过程被篡改”，前提是哈希值本身是通过可信渠道获得的；后者对抗的是“传输或存储中的意外损坏”。同样是SHA-256，这两类场景的信任模型不一样。
做文件发布校验时，哈希值最好跟发布包分开渠道传播。如果攻击者同时篡改了文件内容和官网上展示的哈希值，那校验就形同虚设。实际项目中，我一般把哈希值放到签名文件中，或者直接从构建服务器读取，并配合HTTPS传输。进一步说，如果发布流程里有可信任的签名私钥，建议对哈希值再做一次数字签名，这样校验方就能确认“哈希值来自官方”。
4.3 在实际项目里，SHA需要配合哪些机制
第一是时间戳。很多场景不只是要验证内容没变，还要验证“在某个时间点之前内容就是这个样子”，这需要可信时间戳服务配合。第二是随机数。如果你的系统需要一个防碰撞的标识，比如生成短链接或唯一文件名，用SHA-256对“随机数+内容”做哈希可以降低碰撞概率，但主要随机性还是要依赖安全的随机源。第三是审计日志。哈希值本身只能检测内容是否变化，不能告诉你谁在什么时候改了内容，所以要有配套的日志和权限系统。
我不建议你把SHA当成一个万能安全组件。它是密码学工具箱里的一块积木，只有跟其他机制组合起来才能撑起一个完整的安全边界。
5. 常见问题与排查技巧实录
写哈希工具类看似容易，实际一跑起来问题一堆。这一节我把这些年频率最高的问题和排查思路整理成一个速查清单。每个问题都是我在实际项目里真遇到过的，不是凭空想的。
5.1 同一个字符串为什么我算出来和工具站不一样
八成是字符集问题。你代码里用的是平台默认字符集，而某些在线工具站默认用UTF-8，如果你的运行环境是GBK，结果当然不一样。排查方法很简单：在代码里显式打印出text.getBytes()的字节长度，跟工具站的输入字节长度对比。如果字节数都不一样，说明底层编码已经错了。还有一个小概率原因是在线工具站把输入当成Base64解码后再哈希，这种情况需要你先确认对方工具的输入处理逻辑。
5.2 每次启动计算结果不同是怎么回事
正常业务里，同一个输入得到同一个哈希是基本要求，如果结果不稳定，第一检查点是你有没有往输入里混入随机盐。盐本身是随机的，如果你在计算用户密码哈希时每次生成新盐，当然每次都不同——这其实是正确行为。但如果你确认输入完全一致却得到不同结果，那就要看是不是MessageDigest实例被多线程共享了。前面说过它不是线程安全的，两个线程同时digest会导致内部状态互相覆盖。建议每个计算入口都新建实例，或者用ThreadLocal隔离。
5.3 文件哈希校验不通过，先检查这三处
第一，文件传输过程中是否被转换过换行符。Windows的\r\n和Linux的\n是不同字节，上传下载工具有时会自动转换，这会让哈希完全变掉。第二，文件尾部是否有额外数据。很多下载工具会给文件追加.part后缀或者元数据段，直接改后缀名续传可能导致字节不一致。第三，你的缓冲区读取是否漏掉了最后一次不满一个缓冲区的数据。如果代码里用了update(buffer)而不是update(buffer, 0, len)，结果必错。
5.4 性能“真慢”？先看是不是在代码结构上犯浑
我见过最夸张的一个案例，某个服务计算短字符串哈希时，每次请求都新建MessageDigest实例，同时用String.format去拼接Hex，结果在双核小机器上，TPS只能跑到几百。排查后发现，瓶颈根本不在算法本身，而在Hex转换和对象创建上。把String.format换掉之后，性能直接翻了十几倍。所以如果你觉得SHA-256慢，先别急着上并发，先用JMH或简单的System.nanoTime()做个基准测试，看看CPU时间到底花在哪。
5.5 排查方法清单与工具推荐
我现在排查哈希问题有一套固定流程：先固定输入编码（强制UTF-8），再固定输出格式（统一小写Hex），最后固定算法名（连字符大写）。按这个顺序检查，90%的问题都能定位。如果还找不到问题，就写一个最小复现类，把输入、中间字节、输出全部打印出来，跟开源工具站逐一比对，很容易看出差异在哪一步。
工具方面，除了在线哈希工具站，我常用openssl命令行在Linux环境中做交叉验证：
echo -n "Hello, World!" | sha256sum echo -n "Hello, World!" | openssl dgst -sha256注意echo -n不能丢，丢了会多算一个换行符，结果就跟程序里算了"Hello, World!\n"一样，这是另一个经典坑。
最后给一个常见问题速查表，建议截图或收藏：
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 字符串哈希结果与工具站不一致 | 字符集编码不同 | 显式使用UTF-8取字节 |
返回[B@xxxx | 直接对byte[]调用toString() | 用Hex转换工具类 |
| 大文件计算OOM | 一次性readAllBytes | 改用缓冲区update |
| 并发下偶发结果错误 | MessageDigest被多线程共享 | 改用ThreadLocal或新实例 |
| 密码哈希被破解 | 没有加盐或使用快速哈希 | 改用PBKDF2/bcrypt/Argon2 |
| 文件哈希总跟发布方不同 | 换行符转换或尾部附加数据 | 检查传输工具配置，比对字节数 |
我个人在实际操作中的体会是：SHA算法本身没有太多可钻研的黑魔法，真正的复杂度都藏在工程细节里——字符集、缓冲区、线程隔离、安全边界。你把这几个细节打磨好了，一个看似简单的哈希工具类也会变得很可靠。如果你后续打算做文件秒传系统，或者要在分布式环境里做内容寻址存储，这篇文章里提到的思路完全可以作为起点，只需要把文件块大小的策略和哈希索引的结构再往深处设计一层就行。
