1. 项目概述与核心价值在Java开发中数据安全是一个绕不开的话题。无论是用户密码、敏感配置信息还是需要在网络上传输的业务数据加密都是保护它们的第一道防线。AESAdvanced Encryption Standard高级加密标准作为目前全球广泛使用的对称加密算法因其安全性高、性能好成为了Java开发者工具箱里的标配。但很多朋友在初次接触时往往会卡在一些细节上为什么我的加密结果和别人不一样为什么从数据库解密出来一堆乱码CBC模式和ECB模式到底该用哪个IV初始化向量又是什么这篇文章我就结合自己多年在金融和互联网项目中的实战经验把Java AES加密和解密从原理到代码实现掰开揉碎了讲清楚。我会重点解释那些官方文档里一笔带过但实际开发中却至关重要的“坑点”比如不同工作模式和填充方式的区别、密钥和IV的生成与管理、以及与MySQL等数据库的加解密互通。无论你是正在处理一个需要加密存储用户信息的Web项目还是在设计一个安全的API接口这篇文章提供的代码和思路都能让你直接“抄作业”避开我当年踩过的那些坑。2. AES加密核心原理与模式选择在动手写代码之前我们必须先理解AES是怎么工作的以及几个关键概念的选择会如何影响我们最终的代码实现。这就像做菜你得先知道火候和调料的作用才能炒出一盘好菜。2.1 对称加密与AES算法简述AES是一种对称加密算法。所谓“对称”就是加密和解密使用同一把钥匙密钥。这把钥匙的长度可以是128位、192位或256位。位数越长安全性越高但计算开销也略大。对于绝大多数应用场景128位即16个字节的密钥长度已经足够安全它也是目前最常用的选择。AES加密的过程可以想象成一个非常复杂的“搅拌机”。它把固定大小的“数据块”128位即16字节和“密钥”放进去经过多轮的替换、移位、列混合等操作这些操作统称为轮函数最终输出一个同样大小的“密文块”。解密则是这个过程的逆运算。如果原始数据明文超过16字节就需要把它切成多个16字节的块逐个处理这就是“分组加密”。如何切分、如何处理块与块之间的关系就引出了不同的“工作模式”。2.2 五种工作模式深度解析与选型指南工作模式决定了AES这个“搅拌机”如何处理多个数据块。选错了模式可能会导致安全性问题或功能缺陷。ECB模式 (Electronic Codebook)这是最简单粗暴的模式。每个明文块独立地用同一个密钥加密相同的明文块必然产生相同的密文块。你可以把它想象成用同一本密码本Codebook逐字翻译一篇文章。它的优点是简单、速度快并且每个块的加密可以并行进行。但致命缺点是如果原文中有大量重复的段落比如一张图片的纯色背景那么密文中也会出现明显的重复图案这为攻击者提供了分析突破口。因此在需要保护数据模式的场景下如图像、有固定结构的数据绝对不要使用ECB模式。CBC模式 (Cipher Block Chaining)这是目前最常用、也最推荐的模式。它引入了一个“初始化向量”IV。加密第一个块时先将IV与第一个明文块进行异或XOR操作然后再用密钥加密。加密第二个块时则将第一个块的密文作为新的“IV”与第二个明文块异或后再加密以此类推。这就好比做菜时炒完第一盘菜后锅底留的底油相当于上一块的密文会影响到下一盘菜的味道。这样一来即使两个明文块完全相同加密后的密文块也完全不同完美解决了ECB的模式泄露问题。解密时过程相反。CBC模式的缺点是加密过程无法并行因为需要前一个密文块但解密过程可以并行。CFB模式 OFB模式 (Cipher/Output FeedBack)这两种模式都将分组密码转换为一种“流密码”。它们不是直接加密明文而是先用密钥加密一个“状态值”初始为IV生成一个密钥流然后用这个密钥流与明文进行异或得到密文。CFB模式用密文反馈来更新状态OFB模式用加密后的输出反馈来更新状态。它们的特点是可以处理任意长度的数据不需要填充特别适合实时流数据传输如音视频流。但同样它们的加密过程也无法并行。CTR模式 (CounTeR)CTR模式也可以看作是一种流密码。它使用一个计数器Counter与密钥加密后生成密钥流再与明文异或。计数器的值通常每次加1。它的巨大优势在于加密和解密都可以完全并行化因为每个块的密钥流生成只依赖于计数器的值而不依赖于其他块。这使得CTR模式在需要高性能加解密的场景下如加密大文件非常有优势。模式选择总结通用场景数据安全优先选择 CBC 模式。这是平衡了安全性和实现复杂度的最佳选择也是大多数库和协议的默认或推荐模式。需要加密流数据或数据长度不固定考虑 CFB 或 OFB 模式。追求极致加解密性能且能保证计数器唯一性选择 CTR 模式。除非有特殊兼容性要求否则避免使用 ECB 模式。2.3 填充方案Padding详解AES一次处理一个16字节的块。如果明文长度不是16字节的整数倍最后一个块就需要“填充”到16字节。常见的填充方案有PKCS5Padding / PKCS7Padding这是最常用的填充方式。假设最后一个块还差N个字节那么就填充N个值为N的字节。例如差5个字节就填充0x05 0x05 0x05 0x05 0x05。解密后读取最后一个字节的值就知道需要移除多少填充字节。Java中通常用PKCS5Padding但实际上它处理的是16字节块应称为PKCS7Padding不过JDK内部做了兼容。NoPadding不进行填充。这就要求调用者必须确保明文长度是16字节的整数倍否则会抛出异常。ISO10126Padding与PKCS5类似但除了最后一个字节是填充长度外其余填充字节是随机数安全性稍好。在CBC模式下即使选择了NoPadding如果数据不是16字节的倍数JDK的Cipher实现通常也会在内部用0补全以满足异或运算但解密后这些补全的0也会被保留需要开发者手动截断。因此对于通用文本加密强烈建议使用PKCS5Padding省心省力。3. Java AES加解密代码实战与避坑指南理论讲完我们进入实战环节。这里我会给出两套最常用、也最容易出错的代码实现并附上详细的注释和避坑说明。3.1 基础工具类AES-128-ECB 模式实现ECB模式虽然不安全但因其简单常在一些对安全性要求不高或需要与某些旧系统如特定版本的MySQLAES_ENCRYPT函数兼容的场景下使用。下面的工具类实现了与MySQLAES_ENCRYPT/AES_DECRYPT函数兼容的ECB模式加解密。import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; import java.util.Base64; // 使用JDK8的标准Base64 /** * AES-128-ECB 加解密工具类 * 注意ECB模式不安全仅用于演示或与特定系统如旧版MySQL AES函数兼容。 * 密钥必须为16字节128位。 */ public class AesEcbUtil { private static final String ALGORITHM AES; private static final String TRANSFORMATION AES/ECB/PKCS5Padding; // 算法/模式/填充 /** * ECB模式加密 * param plainText 明文 * param secretKey 密钥必须为16个字符128位 * return Base64编码的密文 */ public static String encrypt(String plainText, String secretKey) throws Exception { // 1. 参数校验 if (secretKey null || secretKey.length() ! 16) { throw new IllegalArgumentException(密钥必须为非空且长度为16位); } // 2. 生成密钥规范 SecretKeySpec secretKeySpec new SecretKeySpec(secretKey.getBytes(UTF-8), ALGORITHM); // 3. 初始化Cipher为加密模式 Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec); // 4. 执行加密 byte[] encryptedBytes cipher.doFinal(plainText.getBytes(UTF-8)); // 5. 使用Base64编码便于传输和存储避免乱码 return Base64.getEncoder().encodeToString(encryptedBytes); } /** * ECB模式解密 * param encryptedText Base64编码的密文 * param secretKey 密钥必须为16个字符128位 * return 解密后的明文 */ public static String decrypt(String encryptedText, String secretKey) throws Exception { // 1. 参数校验 if (secretKey null || secretKey.length() ! 16) { throw new IllegalArgumentException(密钥必须为非空且长度为16位); } // 2. 生成密钥规范 SecretKeySpec secretKeySpec new SecretKeySpec(secretKey.getBytes(UTF-8), ALGORITHM); // 3. 初始化Cipher为解密模式 Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec); // 4. Base64解码 byte[] encryptedBytes Base64.getDecoder().decode(encryptedText); // 5. 执行解密 byte[] decryptedBytes cipher.doFinal(encryptedBytes); // 6. 返回字符串 return new String(decryptedBytes, UTF-8); } public static void main(String[] args) throws Exception { String secretKey 1234567890123456; // 16位密钥 String originalText Hello, AES-ECB!; System.out.println(原文: originalText); String encryptedText encrypt(originalText, secretKey); System.out.println(加密后 (Base64): encryptedText); String decryptedText decrypt(encryptedText, secretKey); System.out.println(解密后: decryptedText); } }避坑点1字符编码一致性注意代码中多次出现的UTF-8。getBytes()和new String()时必须明确指定字符编码否则在不同操作系统如Windows默认GBKLinux默认UTF-8上运行时同样的字符串会得到不同的字节数组导致“密钥错误”或解密后乱码。这是新手最容易踩的坑之一。避坑点2Base64编码的必要性加密后的字节数组是二进制数据可能包含不可打印字符。直接转换成String会丢失信息或产生乱码。使用Base64编码将其转换为纯文本字符串便于在JSON、XML、URL或数据库中安全存储和传输。JDK8及以上推荐使用java.util.Base64替代旧的sun.misc.BASE64Encoder。3.2 推荐方案AES-128-CBC 模式实现更安全对于绝大多数需要安全加密的场景我们都应该使用CBC模式。它需要一个额外的参数初始化向量IV。import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.security.SecureRandom; import java.util.Base64; /** * AES-128-CBC 加解密工具类推荐 * 使用更安全的CBC模式需要密钥和初始化向量(IV)。 * 密钥和IV必须为16字节128位。 * 注意IV不需要保密但必须不可预测且每次加密最好使用不同的IV。 */ public class AesCbcUtil { private static final String ALGORITHM AES; private static final String TRANSFORMATION AES/CBC/PKCS5Padding; private static final int KEY_SIZE 16; // 128位 16字节 /** * 生成一个随机的初始化向量(IV) * return 16字节的随机IV */ public static byte[] generateIv() { byte[] iv new byte[16]; new SecureRandom().nextBytes(iv); // 使用密码学安全的随机数生成器 return iv; } /** * CBC模式加密 * param plainText 明文 * param secretKey 密钥16字节 * param iv 初始化向量16字节 * return Base64编码的密文。实际应用中IV需要和密文一起存储/传输。 */ public static String encrypt(String plainText, byte[] secretKey, byte[] iv) throws Exception { // 参数校验 if (secretKey.length ! KEY_SIZE || iv.length ! KEY_SIZE) { throw new IllegalArgumentException(密钥和IV长度必须为16字节); } SecretKeySpec secretKeySpec new SecretKeySpec(secretKey, ALGORITHM); IvParameterSpec ivParameterSpec new IvParameterSpec(iv); Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec); byte[] encryptedBytes cipher.doFinal(plainText.getBytes(UTF-8)); return Base64.getEncoder().encodeToString(encryptedBytes); } /** * CBC模式解密 * param encryptedText Base64编码的密文 * param secretKey 密钥16字节 * param iv 初始化向量必须与加密时使用的IV相同 * return 解密后的明文 */ public static String decrypt(String encryptedText, byte[] secretKey, byte[] iv) throws Exception { // 参数校验 if (secretKey.length ! KEY_SIZE || iv.length ! KEY_SIZE) { throw new IllegalArgumentException(密钥和IV长度必须为16字节); } SecretKeySpec secretKeySpec new SecretKeySpec(secretKey, ALGORITHM); IvParameterSpec ivParameterSpec new IvParameterSpec(iv); Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec); byte[] encryptedBytes Base64.getDecoder().decode(encryptedText); byte[] decryptedBytes cipher.doFinal(encryptedBytes); return new String(decryptedBytes, UTF-8); } /** * 一个更易用的加密方法内部生成随机IV并拼接在密文前 * 格式: Base64(IV) : Base64(CipherText) * param plainText 明文 * param secretKey 密钥 * return 拼接后的字符串 */ public static String encryptWithIv(String plainText, byte[] secretKey) throws Exception { byte[] iv generateIv(); String cipherText encrypt(plainText, secretKey, iv); String ivBase64 Base64.getEncoder().encodeToString(iv); return ivBase64 : cipherText; // 用分隔符连接 } /** * 解密 encryptWithIv 方法加密的数据 * param combinedText encryptWithIv 返回的字符串 * param secretKey 密钥 * return 明文 */ public static String decryptWithIv(String combinedText, byte[] secretKey) throws Exception { String[] parts combinedText.split(:, 2); if (parts.length ! 2) { throw new IllegalArgumentException(无效的加密数据格式); } byte[] iv Base64.getDecoder().decode(parts[0]); String cipherText parts[1]; return decrypt(cipherText, secretKey, iv); } public static void main(String[] args) throws Exception { // 密钥应该从安全的配置源获取这里仅为演示 String keyStr MySuperSecretKey!; // 16个字符 byte[] secretKey keyStr.getBytes(UTF-8); String originalText 这是一段需要安全加密的敏感数据。; System.out.println(原文: originalText); // 方法一自己管理IV byte[] iv generateIv(); String encryptedText1 encrypt(originalText, secretKey, iv); System.out.println(加密后 (CBC自带IV): encryptedText1); String decryptedText1 decrypt(encryptedText1, secretKey, iv); System.out.println(解密后: decryptedText1); System.out.println(---); // 方法二使用封装方法IV与密文一起返回 String combinedResult encryptWithIv(originalText, secretKey); System.out.println(加密后 (IV密文组合): combinedResult); String decryptedText2 decryptWithIv(combinedResult, secretKey); System.out.println(解密后: decryptedText2); } }核心要点1IV的作用与管理IV的作用是确保即使相同的明文、相同的密钥每次加密也会产生不同的密文从而隐藏明文模式。IV不需要保密但必须不可预测即随机生成且对于同一密钥每次加密都应使用不同的IV。常见的做法是使用SecureRandom生成IV然后将其与密文一起存储或传输如拼接在密文前。解密时再从组合字符串中分离出IV使用。绝对不要使用固定IV或全零IV那会严重削弱CBC模式的安全性。核心要点2密钥的安全存储代码中硬编码密钥是极不安全的。在实际项目中密钥应该存储在环境变量、专用的密钥管理系统如HashiCorp Vault、AWS KMS或经过严格访问控制的配置文件中。密钥是加密体系的根本一旦泄露所有加密数据都可能暴露。4. 高级话题密钥生成、数据库互通与性能优化掌握了基础实现后我们来看看在实际工程中会遇到的一些进阶问题。4.1 安全的密钥生成与管理我们不应该用人脑来想一个密钥。Java提供了KeyGenerator类来生成密码学意义上安全的随机密钥。import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; import java.security.NoSuchAlgorithmException; import java.util.Base64; public class KeyGenDemo { public static void main(String[] args) throws NoSuchAlgorithmException { // 1. 获取AES密钥生成器实例 KeyGenerator keyGen KeyGenerator.getInstance(AES); // 2. 初始化密钥生成器指定密钥长度128, 192, 256 keyGen.init(128); // 也可以是 192 或 256 // 3. 生成密钥 SecretKey secretKey keyGen.generateKey(); // 4. 获取密钥的字节数组 byte[] keyBytes secretKey.getEncoded(); // 5. 可以转换为Base64字符串方便存储但存储本身需安全 String base64Key Base64.getEncoder().encodeToString(keyBytes); System.out.println(生成的密钥 (Base64): base64Key); System.out.println(密钥长度 (字节): keyBytes.length); // 后续可以将 base64Key 安全地存储起来使用时再解码回 byte[] // byte[] loadedKey Base64.getDecoder().decode(base64Key); // SecretKeySpec keySpec new SecretKeySpec(loadedKey, AES); } }注意生成的密钥是随机的二进制数据。将其转换为Base64字符串只是为了便于在文本配置中表示。这个字符串本身就和密钥一样敏感必须妥善保管。4.2 与MySQL数据库的AES函数互通很多业务场景下我们希望在Java端加密数据存入数据库然后既能用Java解密也能直接用SQL语句在数据库层面进行查询和解密。MySQL提供了AES_ENCRYPT()和AES_DECRYPT()函数。关键点在于MySQL的AES函数默认使用ECB模式且填充方式比较特殊。它并不是标准的PKCS5/PKCS7填充。为了让Java与MySQL互通我们需要在Java端模拟MySQL的填充行为。经过测试MySQL 5.7及以上版本的AES_ENCRYPT函数在数据不是16字节倍数时使用的是“用0x00字节填充到16的倍数”的方式。同时它默认使用ECB模式。因此对应的Java代码需要做如下调整import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; import java.util.Base64; public class MysqlCompatibleAESUtil { /** * 模拟 MySQL AES_ENCRYPT 函数 * 算法AES/ECB/NoPadding但需手动进行零填充 */ public static String encryptLikeMysql(String plainText, String secretKey) throws Exception { if (secretKey.length() ! 16) { throw new IllegalArgumentException(MySQL AES key must be 16 bytes); } byte[] keyBytes secretKey.getBytes(UTF-8); byte[] plainBytes plainText.getBytes(UTF-8); // 手动进行零填充 int blockSize 16; int paddedLength ((plainBytes.length blockSize - 1) / blockSize) * blockSize; byte[] paddedPlainBytes new byte[paddedLength]; System.arraycopy(plainBytes, 0, paddedPlainBytes, 0, plainBytes.length); // 剩余部分已经是0 (Java数组初始化默认值为0) SecretKeySpec keySpec new SecretKeySpec(keyBytes, AES); Cipher cipher Cipher.getInstance(AES/ECB/NoPadding); // 注意是NoPadding cipher.init(Cipher.ENCRYPT_MODE, keySpec); byte[] encryptedBytes cipher.doFinal(paddedPlainBytes); // MySQL的AES_ENCRYPT返回的是二进制我们这里用Base64表示 // 实际存储到MySQL BLOB字段时可以直接存字节数组 return Base64.getEncoder().encodeToString(encryptedBytes); } /** * 模拟 MySQL AES_DECRYPT 函数 */ public static String decryptLikeMysql(String base64CipherText, String secretKey) throws Exception { byte[] keyBytes secretKey.getBytes(UTF-8); byte[] encryptedBytes Base64.getDecoder().decode(base64CipherText); SecretKeySpec keySpec new SecretKeySpec(keyBytes, AES); Cipher cipher Cipher.getInstance(AES/ECB/NoPadding); cipher.init(Cipher.DECRYPT_MODE, keySpec); byte[] decryptedPaddedBytes cipher.doFinal(encryptedBytes); // 去除末尾的零填充。找到最后一个非零字节的位置。 int idx decryptedPaddedBytes.length; while (idx 0 decryptedPaddedBytes[idx - 1] 0) { idx--; } byte[] decryptedBytes new byte[idx]; System.arraycopy(decryptedPaddedBytes, 0, decryptedBytes, 0, idx); return new String(decryptedBytes, UTF-8); } public static void main(String[] args) throws Exception { String key 1234567890123456; String text Hello MySQL AES; String encrypted encryptLikeMysql(text, key); System.out.println(Java加密 (模拟MySQL): encrypted); // 对应的MySQL查询应该是 // SELECT TO_BASE64(AES_ENCRYPT(Hello MySQL AES, 1234567890123456)); // 两者输出的Base64字符串应该是一致的。 String decrypted decryptLikeMysql(encrypted, key); System.out.println(Java解密: decrypted); } }重要提示这种零填充方式存在歧义。如果明文本身末尾就有合法的0x00字节解密时将无法区分哪些是填充、哪些是原始数据。因此仅在与MySQL AES函数互通的特定场景下使用此方法。在新的跨系统设计中更推荐使用标准的PKCS5Padding和CBC模式并在各端Java、数据库、其他语言使用统一的、标准的加密库来实现。4.3 性能考量与最佳实践Cipher对象复用Cipher.getInstance()是一个比较耗时的操作因为它需要加载类、验证转换字符串。在需要频繁加解密的场景如Web请求中对每个字段加解密应该将初始化好的Cipher对象缓存起来例如使用ThreadLocal避免重复创建。选择适合的模式如果加密大量数据如文件且不需要CBC模式的安全性增益例如已在其他层面保证了数据模式安全可以考虑使用CTR模式以获得并行加密的性能优势。密钥长度128位密钥在可预见的未来都是安全的。使用256位密钥会略微增加计算开销但安全性提升在当前技术背景下并不显著。除非有合规性要求如某些金融标准否则128位是性价比最高的选择。异常处理加解密操作可能抛出多种异常如BadPaddingException通常意味着密钥或IV错误、IllegalBlockSizeException数据长度不对等。在生产代码中应该捕获这些异常并转换为业务友好的错误信息而不是直接将栈轨迹抛给用户。5. 常见问题排查与实战技巧在实际开发中你几乎一定会遇到下面这些问题。我把它们和解决方案整理成了表格方便你快速查阅。问题现象可能原因排查步骤与解决方案解密时抛出javax.crypto.BadPaddingException: Given final block not properly padded1.密钥错误加密和解密使用的密钥不一致。2.IV错误CBC模式加密和解密使用的IV不一致。3.数据被篡改密文在传输或存储过程中发生了改变。4.填充方式不匹配加密用PKCS5解密用NoPadding或与MySQL等外部系统填充方式不一致。1.核对密钥确保加解密双方的密钥字符串完全一致包括大小写和空格。使用调试工具打印密钥的字节数组或Base64编码进行比对。2.核对IV确保CBC模式下解密时使用的IV与加密时生成的IV完全相同。检查IV的存储和传输逻辑。3.检查数据完整性确保密文没有被截断或修改。可以考虑在加密后对密文计算MAC消息认证码或使用AEAD模式如GCM。4.统一填充方案确保加解密双方使用相同的填充方案。与外部系统交互时务必查明对方使用的具体填充规则。解密后得到乱码1.字符编码不一致加密时用UTF-8解密时用GBK或反之。2.Base64编解码问题加密后未做Base64编码直接转字符串或解密前未正确Base64解码。3.数据截断密文在传输过程中可能被不恰当地处理如存入数据库VARCHAR字段时被截断。1.强制指定编码在所有getBytes()和new String()的地方显式指定UTF-8。2.验证Base64确保加密后一定经过Base64编码再输出解密前一定先对输入字符串进行Base64解码。可以使用在线的Base64编解码工具验证中间结果。3.使用二进制字段将密文Base64字符串或字节数组存入数据库时使用BLOB、VARBINARY或TEXT/LONGTEXT字段避免使用VARCHAR可能因字符集转换出问题。加密后的结果每次都不一样CBC模式这是正常且正确的行为如果使用了随机生成的IV即使相同的明文和密钥每次加密结果也会不同。这正是CBC模式安全性的体现。只要解密时使用对应的IV即可。无需处理。确保将IV随密文一起保存和传输。加密后的结果每次都不一样ECB模式不正常ECB模式是确定性加密相同输入必然产生相同输出。如果结果不同说明密钥或明文在每次加密前发生了变化例如字符串包含了时间戳等可变部分。检查加密函数的输入参数明文和密钥是否每次调用都完全一致。与第三方如PHP、Python加解密结果不一致1.模式/填充不匹配双方使用的AES模式ECB/CBC等或填充方案PKCS5/NoPadding等不同。2.密钥/IV处理不同密钥或IV的字符串到字节数组的转换方式不同如编码差异。3.Base64差异可能存在URL安全的Base64、标准Base64、是否添加换行等差异。1.对齐算法字符串这是最关键的一步。确保双方使用的算法标识字符串完全一致。例如Java的AES/CBC/PKCS5Padding对应OpenSSL的aes-128-cbc和PKCS7填充与PKCS5兼容。2.统一编码约定双方都使用UTF-8编码将字符串转换为字节。3.统一Base64约定使用标准Base64不换行。可以使用一个简单的字符串如test进行双向加解密联调。InvalidKeyException: Illegal key size这是因为使用了超过128位的密钥如192或256位而Java运行环境受限于默认的JCE策略文件。1.方案一推荐下载并安装Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files覆盖JRE的lib/security目录下的对应jar包。2.方案二使用128位密钥这对绝大多数应用已足够安全。我个人在实际项目中的几点心得密钥管理是核心不要将密钥写在代码里。我通常的做法是在应用启动时从环境变量或中心配置服务读取一个“密钥加密密钥”KEK然后用这个KEK去解密存储在安全配置文件中的“数据加密密钥”DEK。这样即使配置文件泄露攻击者没有KEK也无法解密DEK。为加密数据添加“版本”或“上下文”信息在存储或传输加密数据时可以在密文前附加一个简短的头部例如v1:CBC:其中v1表示算法版本CBC表示模式。这样未来如果需要升级加密算法比如从AES-128-CBC升级到AES-256-GCM可以平滑过渡系统能够根据头部信息选择对应的解密方法。考虑使用认证加密上述的CBC模式只提供了保密性没有提供完整性数据是否被篡改。更现代的做法是使用GCMGalois/Counter Mode这样的认证加密模式它同时提供保密性和完整性。Java中可以通过AES/GCM/NoPadding来使用。这通常是比CBC更推荐的选择但实现上稍微复杂一点需要处理认证标签Tag。单元测试至关重要为你的加密工具类编写全面的单元测试包括使用固定密钥和IV验证加解密可逆模拟与已知第三方输出结果的对比测试对异常输入空值、错误长度密钥的处理。这能极大避免线上故障。最后记住加密只是安全链条中的一环。安全的系统设计、严格的访问控制、及时的漏洞修复同样重要。希望这篇长文能帮你彻底搞懂Java中的AES加解密在项目中游刃有余地应用它。如果在实践中遇到新的问题多从模式、填充、编码、密钥/IV这几个核心维度去排查大部分问题都能迎刃而解。