老服务升到 JDK 17，解密历史数据时报 InvalidKeyException: Illegal key size，密钥是 256 位 AES，同样的代码在 JDK 8 上正常。乍看像缓存或者权限的锅，追下去往往不是。
java -version mvn dependency:tree -Dincludes=org.bouncycastle java -XshowSettings:security -version 2>&1 | grep -i provider
追下去是这么回事：JDK 8 早期受出口限制，256 位密钥要额外装 JCE 无限强度策略文件。JDK 9 之后默认就开启了，问题多半出在依赖里的旧版 bcprov 或 security provider 顺序。
「JDK17 加密算法」相关的日志我一般连着看前后五分钟，单看一条报错经常判断不出是哪一步失败。验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。报错里带路径的，先去看那个路径在不在、权限对不对。
同一份配置存在多处的，先确认改的是被加载的那一份。新版本先放一台机器上跑一天再全量，问题一般在这段时间暴露。
具体做法是，先确认报错堆栈里的 Provider 是 SunJCE 还是 BouncyCastle；用 Security.getProviders 打印实际加载顺序；排掉旧版 bcprov 或升到与 JDK 17 匹配的版本；必要时在 java.security 里调整 provider 顺序。
验收就看一点，Provider 列表里 bcprov 版本与 JDK 17 匹配 解密 256 位 AES 不再抛 InvalidKeyException。