1. 问题背景与核心痛点拆解

Java 1.8 环境下用 AES 或 DES 做加解密，本地跑得好好的，一打包成可执行 JAR 或者丢到服务器上运行，直接抛异常——这个场景我见过太多次了。报错信息通常长这样：java.security.NoSuchAlgorithmException: AES/ECB/PKCS5Padding SecretKeyFactory not available，或者javax.crypto.BadPaddingException: Given final block not properly padded，再或者更隐蔽的InvalidKeyException: Illegal key size。表面上看是加密算法不可用，实际上背后的原因五花八门，从 JDK 版本差异、打包方式、依赖冲突到运行环境的安全策略，每一个环节都可能埋雷。

这篇文章就是要把这个坑彻底挖开。我会从问题根因分类、排查思路、具体解决方案、代码层面的防御性写法、打包配置的注意事项以及不同部署场景下的适配策略几个维度展开，把 AES/DES 在 Java 1.8 打包后不可用这件事讲透。适合所有在 Java 后端做数据安全、接口签名、敏感字段加密的开发者，尤其是那些正在被NoSuchAlgorithmException折磨的同学。

先说一个基本认知：Java 的加密体系叫JCA（Java Cryptography Architecture），它是一套 Provider 架构。Cipher.getInstance("AES")这行代码背后，JVM 会去查找注册的 Security Provider 列表，找到能提供 AES 实现的那个 Provider。如果找不到，就抛NoSuchAlgorithmException。所以“算法不可用”的本质是Provider 没注册、Provider 被覆盖、或者算法名称不匹配。理解了这一点，后面所有排查都有了方向。

另外还有一个高频误区：很多人以为AES就是AES/ECB/PKCS5Padding，实际上Cipher.getInstance("AES")在不同 JDK 实现下默认的 mode 和 padding 可能不同。SunJCE Provider 对AES的默认转换是AES/ECB/PKCS5Padding，但这个默认值并不是 JCA 规范强制的，换一个 Provider 就可能变。所以生产环境永远建议写全称：AES/GCM/NoPadding或者AES/CBC/PKCS5Padding，不要偷懒。

2. 根因分类：为什么打包后算法就“消失”了

2.1 JDK 版本与 JCE 策略文件的差异

Java 1.8 早期版本（8u151 之前）对 AES 的密钥长度有限制。默认的local_policy.jar和US_export_policy.jar只允许 128 位密钥，如果你用 256 位 AES 密钥，会直接抛InvalidKeyException: Illegal key size。这个问题在 8u151 之后被官方通过UnlimitedJCEPolicy默认启用的方式解决了，但很多老项目跑在 8u144、8u131 甚至更早的版本上，打包后换了一台机器，JDK 小版本不同，问题就暴露了。

判断方法很简单，跑一行代码：

System.out.println(Cipher.getMaxAllowedKeyLength("AES"));

如果输出 128，说明当前 JRE 还是受限策略；输出 2147483647 才是无限制。这个差异在本地开发机和生产服务器之间极其常见，因为开发机可能装的是新版 JDK，服务器上跑的是几年前的老版本。

2.2 打包方式导致的 Provider 丢失

用 Maven Shade Plugin 打 fat jar 的时候，如果没有正确配置ServicesResourceTransformer，META-INF/services/java.security.Provider文件会被覆盖或丢弃。JCA 的 Provider 注册依赖 SPI 机制，这个文件没了，第三方 Provider（比如 BouncyCastle）就注册不上。表现就是本地 IDE 里跑没问题（因为 classpath 里有完整的 jar），打包后Security.getProviders()里少了一截。

还有一种情况是用了 Spring Boot 的spring-boot-maven-plugin，它默认的PropertiesLauncher和JarLauncher对META-INF/services的处理方式不同。如果你的加密实现依赖某个第三方库的 SPI 注册，打包后类加载器层级变了，ServiceLoader找不到实现类，同样会报算法不可用。

2.3 依赖冲突与 Provider 覆盖

项目里同时引入了多个加密相关库——比如 BouncyCastle、Apache Commons Codec、还有某个中间件自带的加密包——它们的 Provider 名称可能冲突。JCA 在查找算法时是按 Provider 注册顺序遍历的，如果前面注册的 Provider 声称支持 AES 但实现有问题，或者版本不兼容，就会导致Cipher.getInstance拿到一个错误的实现，运行时才抛异常。

更隐蔽的是，某些容器（如 Tomcat、WebLogic）会预注册自己的 Security Provider，你的应用跑在容器里，Provider 列表被容器改过，行为跟独立运行完全不一样。这类问题在本地main方法测试时根本复现不了。

2.4 模块化与类加载器隔离

Java 9 引入模块化之后，java.base模块对java.crypto包的导出做了限制。虽然 Java 1.8 没有模块系统，但如果你用的某些框架（比如 OSGi、自定义 ClassLoader 的热部署方案）做了类隔离，javax.crypto.Cipher这个类可能被不同的 ClassLoader 加载了多份，导致 Provider 注册表和实际调用的类不在同一个命名空间里。这种情况报错信息往往很诡异，比如ClassCastException或者NoClassDefFoundError夹杂着NoSuchAlgorithmException。

3. 排查思路：五步定位法

遇到“打包后加密算法不可用”，不要上来就改代码，按下面这个顺序排查，能省掉大量试错时间。

第一步，确认报错的具体异常类型。NoSuchAlgorithmException是 Provider 找不到算法；InvalidKeyException是密钥长度或格式问题；BadPaddingException是填充模式不匹配；NoSuchPaddingException是填充算法不可用。不同异常对应完全不同的解决路径，先把异常栈完整打出来，别只看第一行。

第二步，在目标运行环境打印 Provider 列表。加一段临时代码：

for (Provider p : Security.getProviders()) { System.out.println(p.getName() + " -> " + p.getVersion()); }

对比本地和打包后的输出，看少了哪个 Provider。如果 BouncyCastle 不在列表里，那就是 SPI 注册文件丢了。

第三步，检查 JDK 小版本和 JCE 策略。用前面那行getMaxAllowedKeyLength确认密钥长度限制。同时java -version看具体 build 号，8u151 是个分水岭。

第四步，检查打包产物的META-INF/services目录。用jar tf your-app.jar | grep META-INF/services看有没有java.security.Provider文件，内容是否完整。fat jar 合并多个 jar 的 SPI 文件时，如果没用ServicesResourceTransformer，只会保留最后一个，前面的全丢。

第五步，最小化复现。写一个只包含加密逻辑的 main 方法，用同样的打包方式打出来，在目标环境跑。如果最小化复现能通过，说明是依赖冲突；如果还是失败，说明是环境或打包配置问题。这一步能快速缩小范围。

4. 解决方案：从代码到打包的完整适配

4.1 代码层面：显式指定 Provider 和完整算法名

最稳妥的写法是不要依赖默认 Provider，显式指定：

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding", "SunJCE");

如果用了 BouncyCastle，就指定"BC"。这样即使 Provider 列表顺序变了，也能拿到确定的实现。同时算法名写全称，避免默认值差异。

对于密钥长度问题，如果确实需要 256 位 AES 且运行环境是受限策略，有两个选择：一是升级 JDK 到 8u151 以上；二是手动替换 JCE 策略文件。替换的方式是把local_policy.jar和US_export_policy.jar覆盖到$JAVA_HOME/jre/lib/security/目录下。但注意，这个操作在生产环境需要评估合规性，不是所有场景都允许。

4.2 打包配置：Maven Shade Plugin 的正确姿势

如果用了 BouncyCastle 或者其他依赖 SPI 注册的加密库，maven-shade-plugin必须加ServicesResourceTransformer：

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-shade-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <phase>package</phase> <goals><goal>shade</goal></goals> <configuration> <transformers> <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/> <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> <mainClass>com.example.Main</mainClass> </transformer> </transformers> </configuration> </execution> </executions> </plugin>

ServicesResourceTransformer会把所有 jar 里的META-INF/services文件合并，而不是覆盖。这一步不做，BouncyCastle 的 Provider 就注册不上。

如果是 Spring Boot 项目，spring-boot-maven-plugin默认已经处理了 SPI 合并，但要注意layout配置。用JarLauncher时，依赖 jar 被放在BOOT-INF/lib下，由自定义 ClassLoader 加载，ServiceLoader的查找路径跟普通 fat jar 不同。如果遇到问题，可以临时改成PropertiesLauncher测试，确认是不是类加载器的问题。

4.3 运行时注册：兜底方案

如果打包配置一时改不了，可以在应用启动时手动注册 Provider：

static { if (Security.getProvider("BC") == null) { Security.addProvider(new BouncyCastleProvider()); } }

这段代码放在工具类的静态块里，确保在任何加密操作之前执行。对于 SunJCE 这种 JDK 自带的 Provider，一般不需要手动注册，但如果被容器移除了，也可以手动Security.addProvider(new com.sun.crypto.provider.SunJCE())。不过 SunJCE 在 Java 9 之后属于内部 API，Java 1.8 下没问题，升级 JDK 时要留意。

4.4 密钥管理：避免硬编码和格式错误

很多“算法不可用”其实是密钥格式不对导致的。AES 密钥必须是 16、24 或 32 字节，DES 密钥必须是 8 字节。从字符串转密钥时，new SecretKeySpec(key.getBytes(), "AES")这行代码如果key.getBytes()的长度不对，会抛InvalidKeyException，但异常信息有时候会误导人。

建议用 Base64 编码存储密钥，解码后校验长度：

byte[] keyBytes = Base64.getDecoder().decode(base64Key); if (keyBytes.length != 16 && keyBytes.length != 24 && keyBytes.length != 32) { throw new IllegalArgumentException("Invalid AES key length: " + keyBytes.length); } SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES");

DES 的密钥长度校验同理，必须是 8 字节。另外注意getBytes()不指定字符集时会用平台默认编码，不同服务器上可能不一样，统一用StandardCharsets.UTF_8。

5. 常见问题速查表与避坑经验

下面这张表是我在实际项目中遇到过的典型问题汇总，按报错信息分类，方便快速定位。

几个避坑经验值得单独说。第一，不要用Cipher.getInstance("AES")这种简写，虽然本地能跑，但换环境就可能出问题，写全称是成本最低的防御。第二，DES 已经不安全了，新项目一律用 AES，DES 只在维护老系统时用，而且要注意 DES 的密钥只有 56 位有效位，8 字节里每个字节的最后一位是校验位，实际强度很低。第三，CBC 模式必须配随机 IV，不要用固定 IV，否则同样的明文加密出来结果一样，等于泄露信息。IV 可以跟密文一起传输，不需要保密，但必须每次加密都不同。

还有一个容易被忽略的点：打包后的 jar 在 Windows 和 Linux 上跑，默认字符集可能不同。如果密钥或明文涉及字符串转换，一定要显式指定UTF-8。我见过一个案例，本地 Windows 开发机跑得好好的，部署到 Linux 服务器后解密失败，排查了半天发现是getBytes()用了平台默认编码，Windows 是 GBK，Linux 是 UTF-8，字节数组不一样，密钥自然对不上。

6. 不同部署场景的适配策略

6.1 独立 JAR 运行

这是最简单的情况，只要打包配置正确，JDK 版本一致，基本不会出问题。关键是确保META-INF/services合并正确，以及运行环境的 JDK 跟编译时一致。建议在MANIFEST.MF里加上Build-Jdk信息，方便排查。

6.2 传统 Web 容器部署

Tomcat、Jetty 这类容器会预注册一些 Provider，而且容器的 ClassLoader 层级跟独立运行不同。如果应用里用了 BouncyCastle，建议在ServletContextListener的contextInitialized里手动注册，确保在容器初始化完成后、业务代码执行前完成注册。另外注意容器的common.loader配置，如果 BouncyCastle 的 jar 放在容器 lib 目录下，可能跟应用内的版本冲突。

6.3 微服务与容器化部署

Docker 镜像里的 JDK 版本往往跟开发机不一致，这是高频翻车点。建议在 Dockerfile 里显式指定 JDK 版本，并且把getMaxAllowedKeyLength的检查加到健康检查里。另外容器内存限制可能影响SecureRandom的初始化，导致加密操作阻塞，这个坑在低配容器里特别常见。解决办法是在 JVM 参数里加-Djava.security.egd=file:/dev/./urandom，避免/dev/random阻塞。

6.4 多环境配置管理

开发、测试、生产环境的密钥应该不同，但算法和 mode/padding 必须一致。建议把加密配置抽成独立的配置文件，用@ConfigurationProperties或者类似的机制加载，避免硬编码。密钥用环境变量或者配置中心注入，不要写在代码里。这样即使换环境，算法层面的行为也是一致的，不会出现“测试环境能解密、生产环境报算法不可用”这种问题。

7. 写在最后

加密算法在打包后不可用，说到底是一个环境一致性问题。本地开发机的 JDK、依赖、ClassLoader 层级跟打包后的运行环境总有差异，而 JCA 的 Provider 机制又对这些差异特别敏感。我的经验是，与其出了问题再排查，不如在项目初期就把这几件事做掉：算法名写全称、显式指定 Provider、打包配置加 SPI 合并、启动时兜底注册、密钥长度做校验。这五步做完，90% 的“算法不可用”问题都能提前规避。

另外提醒一句，Java 1.8 虽然还在广泛使用，但它的加密体系确实有些历史包袱，尤其是 JCE 策略文件和 Provider 注册机制。如果项目允许，升级到更新的 LTS 版本能省掉很多这类麻烦。如果暂时升不了，那就把上面这些防御性写法落实到代码里，至少能保证换环境的时候不会突然翻车。