1. 项目概述为什么要在小程序与后端间实现AES加解密最近在做一个需要处理敏感信息的项目比如用户身份证号、手机号或者一些交易凭证。前端用的是微信小程序后端是Java的Spring Boot服务。数据在网络里跑来跑去直接用明文传输心里总是不踏实感觉像是在互联网上“裸奔”。虽然HTTPS能解决传输层的安全问题但有时候我们希望对数据本身也做一层加密实现所谓的“端到端加密”这样即使传输过程被窥探或者数据在服务器日志、数据库里被意外看到也只是一堆乱码。这就是我决定在微信小程序和Java后端之间实现AES加解密的直接原因。AES高级加密标准是一种对称加密算法速度快、安全性高是目前应用最广泛的加密标准之一。对称加密意味着加密和解密使用同一把密钥这在小程序与固定服务器通信的场景下非常合适。整个流程可以概括为小程序端用密钥将敏感数据加密成密文传给Java后端Java后端用同样的密钥解密拿到原始明文进行处理返回数据时如果需要也可以同样加密。这个方案听起来简单但实操起来两边小程序JavaScript和Java的加解密结果要对得上需要考虑的细节可不少比如加密模式、填充方式、密钥长度、初始向量等等任何一个参数对不上解密就会失败。接下来我就把这次踩坑和填坑的完整过程以及核心的代码实现给大家拆解清楚。2. 核心思路与方案选型如何让JS和Java“说同一种加密语言”要让微信小程序里的JavaScript和Java后端成功加解密最关键的是确保双方使用完全相同的加密参数和流程。这就像两个人约好了一个暗号不仅要知道暗号是什么还得知道怎么对、什么时候对。如果一方用英语语法另一方用中文语法即使单词一样也解不出正确意思。2.1 加密算法与模式选择首先AES只是一个基础算法块它需要配合不同的“工作模式”和“填充方案”才能使用。常见的模式有ECB、CBC、CFB等。ECB模式最简单但不安全因为相同的明文块会加密成相同的密文块容易暴露出数据模式。CBC模式则安全得多它引入了“初始向量IV”的概念使得即使明文相同加密后的密文也会不同极大地增强了安全性。因此在绝大多数需要安全性的场景下CBC模式是首选。我的项目也选择了AES/CBC/PKCS5Padding这个组合。这里PKCS5Padding是填充方式因为AES加密要求数据长度必须是16字节128位的整数倍对于不够长的数据就需要进行填充。2.2 密钥与初始向量管理对称加密的核心是密钥。AES支持128、192、256位三种密钥长度。我选择了最常用的128位16字节。密钥绝对不能硬编码在客户端代码里那等于把钥匙挂在门上。一个更安全的做法是在首次安全连接如用户登录后由服务端动态生成一个随机的AES密钥和IV通过HTTPS通道下发给小程序端。小程序端将其存储在本地缓存如wx.setStorageSync中用于本次会话的后续通信。会话结束后如用户退出本地密钥即被清除。这样实现了会话级别的动态密钥安全性更高。当然对于某些对实时性要求不高、且需要服务端解密的场景也可以由服务端固定一个密钥但务必通过安全的方式配置绝不能前端暴露。初始向量IV在CBC模式中至关重要它必须是16字节的随机值且不需要保密但同一个密钥下每次加密最好使用不同的IV或者至少保证IV的唯一性。通常我们可以将IV和密文一起传输解密时先取出IV再解密。一种常见的做法是将IV拼接在密文前面组成最终的传输字符串。2.3 数据格式约定加密后的数据是二进制字节不方便在JSON等文本协议中传输。因此我们需要将其编码成文本格式。Base64编码是最通用的选择它能将二进制数据转换成由A-Z、a-z、0-9、、/组成的字符串非常适合网络传输。所以我们的流程将是明文 - AES加密生成字节数组- Base64编码生成字符串- 传输。解密则是逆向过程收到字符串 - Base64解码得到字节数组- AES解密得到字节数组- 转换成原始明文如UTF-8字符串。3. 微信小程序端实现详解小程序端我们使用微信开发者工具核心是调用其提供的WX-Worker或直接使用crypto-js库不微信小程序环境有自己的一套。经过实测最稳定、兼容性最好的方式是使用小程序自带的wx.getRandomValues获取随机数用于生成IV以及使用CryptoJS这个库的定制版本或者更直接地使用一个纯JavaScript实现的AES库比如crypto-js。但需要注意小程序对npm包的支持需要开启并且有些包可能需要手动调整。我这里采用一个经过验证的、轻量级的方案使用miniprogram-sm-crypto这个开源库。它专为小程序优化体积小支持国密算法和AES。我们通过npm安装它。首先在小程序项目根目录下执行命令安装npm install miniprogram-sm-crypto --production安装完成后在微信开发者工具中点击“工具” - “构建npm”。3.1 核心加密函数封装我们在小程序端创建一个工具文件比如utils/crypto.js。// utils/crypto.js const smCrypto require(miniprogram-sm-crypto); // 这里假设密钥Key和初始向量IV由服务端在登录后下发并存储在全局变量或Storage中 // 以下为示例实际应从安全存储中读取 let aesKey 1234567890123456; // 16字节密钥示例请替换 let aesIv abcdefghijklmnop; // 16字节IV示例请替换 /** * AES-CBC-PKCS7 加密 (PKCS7在JS中常等同于PKCS5) * param {string} data - 待加密的明文 * param {string} key - 16字节密钥字符串 * param {string} iv - 16字节初始向量字符串 * return {string} Base64编码的密文 */ function encryptAES(data, key aesKey, iv aesIv) { try { // 确保key和iv是16字节字符串 if (key.length ! 16 || iv.length ! 16) { throw new Error(密钥或初始向量长度必须为16字节); } // 将字符串密钥和IV转换成WordArray格式crypto-js内部格式 // 注意miniprogram-sm-crypto的AES加密参数可能需要Uint8Array格式 // 查阅其文档发现它期望的key和iv是utf8字符串内部会处理 const encrypted smCrypto.aes.encrypt(data, key, { mode: cbc, iv: iv, padding: pkcs7, // 对应Java的PKCS5Padding }); // 加密结果通常是CipherParams对象或直接是base64字符串根据库文档调整 // 该库的encrypt方法返回的是base64字符串 return encrypted; } catch (error) { console.error(AES加密失败:, error); throw new Error(数据加密处理失败); } } /** * AES-CBC-PKCS7 解密 * param {string} base64Cipher - Base64编码的密文 * param {string} key - 16字节密钥字符串 * param {string} iv - 16字节初始向量字符串 * return {string} 解密后的明文 */ function decryptAES(base64Cipher, key aesKey, iv aesIv) { try { if (key.length ! 16 || iv.length ! 16) { throw new Error(密钥或初始向量长度必须为16字节); } const decrypted smCrypto.aes.decrypt(base64Cipher, key, { mode: cbc, iv: iv, padding: pkcs7, }); // 返回解密后的字符串 return decrypted; } catch (error) { console.error(AES解密失败:, error); throw new Error(数据解密处理失败); } } module.exports { encryptAES, decryptAES, aesKey, aesIv };3.2 在业务页面中使用假设我们在一个提交表单的页面中需要加密用户的手机号。// pages/submit/submit.js const crypto require(../../utils/crypto.js); Page({ data: { phoneNumber: }, onInputPhone(e) { this.setData({ phoneNumber: e.detail.value }); }, async submitForm() { const phone this.data.phoneNumber; if (!phone) { wx.showToast({ title: 请输入手机号, icon: none }); return; } // 1. 加密敏感数据 let encryptedPhone; try { encryptedPhone crypto.encryptAES(phone); console.log(加密后的手机号(Base64):, encryptedPhone); } catch (err) { wx.showToast({ title: 数据加密失败, icon: none }); return; } // 2. 将加密后的数据发送给后端 wx.request({ url: https://your-api.com/submit, method: POST, data: { encryptedData: encryptedPhone, // 其他非敏感数据可以直接传 timestamp: Date.now() }, header: { Content-Type: application/json }, success: (res) { // 3. 如果后端返回的数据也是加密的则需要解密 if (res.data.encryptedResponse) { const decryptedData crypto.decryptAES(res.data.encryptedResponse); console.log(解密后的响应:, decryptedData); // 处理业务逻辑... } else { // 处理普通响应 } }, fail: (err) { console.error(请求失败, err); } }); } })注意事项在实际生产环境中aesKey和aesIv绝不应该像上面那样硬编码在JS文件里。它们应该在用户登录成功后由服务端通过HTTPS接口动态下发并存储在小程序的wx.setStorageSync中。每次应用启动或定时刷新可以考虑重新获取以增强安全性。4. Java服务端实现详解服务端我使用Spring Boot框架。Java标准库javax.crypto已经提供了强大的加密支持我们不需要引入额外的加密库。4.1 创建加解密工具类我们创建一个AesUtil工具类集中处理加解密逻辑。package com.yourproject.util; import org.springframework.util.Base64Utils; import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.nio.charset.StandardCharsets; /** * AES加解密工具类 (CBC模式PKCS5Padding) */ public class AesUtil { // 算法/模式/填充 private static final String ALGORITHM AES/CBC/PKCS5Padding; private static final String AES AES; /** * 加密 * param content 明文 * param key 密钥 (16字节) * param iv 初始向量 (16字节) * return Base64编码的密文 */ public static String encrypt(String content, String key, String iv) { try { // 参数校验 if (key null || key.length() ! 16) { throw new RuntimeException(密钥长度必须为16字节); } if (iv null || iv.length() ! 16) { throw new RuntimeException(初始向量长度必须为16字节); } // 1. 创建Cipher实例指定算法 Cipher cipher Cipher.getInstance(ALGORITHM); // 2. 根据密钥字节数组创建SecretKeySpec对象 SecretKeySpec secretKeySpec new SecretKeySpec(key.getBytes(StandardCharsets.UTF_8), AES); // 3. 创建IvParameterSpec对象 IvParameterSpec ivParameterSpec new IvParameterSpec(iv.getBytes(StandardCharsets.UTF_8)); // 4. 初始化Cipher为加密模式 cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec); // 5. 执行加密得到字节数组 byte[] encryptedBytes cipher.doFinal(content.getBytes(StandardCharsets.UTF_8)); // 6. 将加密后的字节数组进行Base64编码返回字符串 return Base64Utils.encodeToString(encryptedBytes); } catch (Exception e) { throw new RuntimeException(AES加密失败, e); } } /** * 解密 * param base64Content Base64编码的密文 * param key 密钥 (16字节) * param iv 初始向量 (16字节) * return 解密后的明文 */ public static String decrypt(String base64Content, String key, String iv) { try { if (key null || key.length() ! 16) { throw new RuntimeException(密钥长度必须为16字节); } if (iv null || iv.length() ! 16) { throw new RuntimeException(初始向量长度必须为16字节); } Cipher cipher Cipher.getInstance(ALGORITHM); SecretKeySpec secretKeySpec new SecretKeySpec(key.getBytes(StandardCharsets.UTF_8), AES); IvParameterSpec ivParameterSpec new IvParameterSpec(iv.getBytes(StandardCharsets.UTF_8)); // 初始化为解密模式 cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec); // 先进行Base64解码得到密文字节数组 byte[] encryptedBytes Base64Utils.decodeFromString(base64Content); // 执行解密 byte[] decryptedBytes cipher.doFinal(encryptedBytes); // 将解密后的字节数组转换成字符串 return new String(decryptedBytes, StandardCharsets.UTF_8); } catch (Exception e) { throw new RuntimeException(AES解密失败, e); } } }4.2 在Spring Boot控制器中使用创建一个REST接口接收小程序加密后的数据。package com.yourproject.controller; import com.yourproject.util.AesUtil; import org.springframework.beans.factory.annotation.Value; import org.springframework.web.bind.annotation.*; RestController RequestMapping(/api) public class DataController { // 从配置文件(application.yml)中读取密钥和IV确保安全 Value(${aes.key}) private String aesKey; Value(${aes.iv}) private String aesIv; PostMapping(/submitEncryptedData) public ApiResponse submitData(RequestBody EncryptedRequest request) { try { // 1. 解密前端传来的数据 String encryptedData request.getEncryptedData(); String decryptedPhone AesUtil.decrypt(encryptedData, aesKey, aesIv); System.out.println(解密后的手机号: decryptedPhone); // 2. 这里进行你的业务逻辑处理比如保存到数据库 // userService.processPhone(decryptedPhone); // 3. 构造响应数据可选将响应数据也加密 String responseData 处理成功手机号尾号 decryptedPhone.substring(decryptedPhone.length() - 4); String encryptedResponse AesUtil.encrypt(responseData, aesKey, aesIv); return ApiResponse.success(操作成功, encryptedResponse); } catch (Exception e) { e.printStackTrace(); return ApiResponse.error(数据处理失败: e.getMessage()); } } // 一个用于下发密钥的接口应在安全验证后调用如登录成功后 GetMapping(/getAesConfig) public ApiResponse getAesConfig(RequestHeader(Authorization) String token) { // 验证token有效性... // if (!tokenService.isValid(token)) { return ApiResponse.error(未授权); } // 可以每次生成新的key和iv增强安全性 // String dynamicKey generateRandomKey(16); // String dynamicIv generateRandomIv(16); // 将dynamicKey和dynamicIv与当前用户会话关联存储如Redis // 这里示例返回固定的配置生产环境应用动态的 AesConfig config new AesConfig(aesKey, aesIv); return ApiResponse.success(获取配置成功, config); } } // 请求体封装 class EncryptedRequest { private String encryptedData; // getters and setters public String getEncryptedData() { return encryptedData; } public void setEncryptedData(String encryptedData) { this.encryptedData encryptedData; } } // 响应体封装 class ApiResponse { private int code; private String message; private Object data; // 构造方法、getters and setters 省略 public static ApiResponse success(String msg, Object data) { return new ApiResponse(0, msg, data); } public static ApiResponse error(String msg) { return new ApiResponse(-1, msg, null); } } // AES配置类 class AesConfig { private String key; private String iv; // 构造方法、getters and setters 省略 }在application.yml中配置密钥aes: key: 1234567890123456 # 16字节密钥 iv: abcdefghijklmnop # 16字节初始向量实操心得密钥管理是安全的重中之重。对于更高安全要求的场景可以考虑使用密钥管理系统KMS或者采用非对称加密如RSA来加密传输对称密钥AES密钥本身。即后端生成RSA公私钥公钥下发给小程序小程序用RSA公钥加密随机生成的AES会话密钥传给后端后端用RSA私钥解密得到AES密钥再进行后续通信。这样即使一次会话的AES密钥被破解也不会影响其他会话。5. 联调与问题排查实录两边代码写好了一联调大概率不会一次成功。下面是我遇到过的几个典型问题及解决方法。5.1 错误一javax.crypto.BadPaddingException: Given final block not properly padded这是最常见的问题意思是“提供的最后一块填充不正确”。根本原因是两端加解密的参数不匹配。请按以下清单逐一核对密钥Key是否一致确保小程序和Java后端使用的密钥字符串完全相同包括长度16字节和每一个字符。初始向量IV是否一致同上必须完全一致。检查传输过程中是否有编码问题。加密模式是否一致必须都是CBC模式。填充方式是否一致Java端是PKCS5Padding小程序端crypto-js或miniprogram-sm-crypto通常对应Pkcs7。在AES中PKCS5和PKCS7在填充上本质是相同的可以互通。但务必确认库的配置项是pkcs7。待加密数据的编码是否一致通常都使用UTF-8。确保在加密前字符串的编码一致。Base64编码解码是否一致有些Base64实现会有差异如是否换行、URL安全等。Java的Base64Utils和小程序常用的btoa/atob或库内置的Base64在标准模式下应该一致。如果遇到问题可以尝试在两端使用相同的Base64工具函数进行比对。排查技巧可以做一个“回声测试”。让小程序加密一个简单的已知字符串如Hello, AES!将密文Base64格式打印出来。同时在Java端用相同的密钥和IV对这个密文进行解密。如果解密失败将Java端解密用的密钥、IV和密文与小程序端打印的进行逐字符比对往往能发现问题。5.2 错误二java.security.InvalidKeyException: Illegal key size这个问题在旧版本的JDK或未安装无限强度管辖权策略文件时可能出现。AES-25632字节密钥默认受策略限制。对于AES-12816字节密钥通常不会遇到此问题。如果使用256位密钥需要为JRE安装JCE无限强度管辖权策略文件。解决方案去Oracle官网下载对应你JDK版本的JCE策略文件。找到你的JAVA_HOME/jre/lib/security目录。用下载包里的local_policy.jar和US_export_policy.jar替换原有的两个文件。重启你的Java应用。更简单的方法是直接使用AES-128它强度足够且没有这个策略限制。5.3 错误三小程序端加密结果每次都不一样但Java端用固定IV解密失败这可能是由于小程序库在加密时自动生成了随机IV并可能将IV混在了输出的密文中例如有些库的输出格式是Salt__IV密文。而你的Java端代码使用的是固定的IV去解密当然会失败。解决方法你需要查看所用小程序加密库的文档明确其输出格式。如果它自动生成并拼接了IV那么你在解密时需要先从传输过来的字符串中解析出IV部分再用这个IV去解密。相应地Java端在加密时也应该生成随机IV并将其与密文一起返回给前端。这是一个更安全的做法。例如假设约定传输格式为Base64(IV) : Base64(密文)。加密端Java生成随机16字节IV加密明文然后将Base64(IV)和Base64(密文)用冒号拼接。解密端小程序收到字符串后按冒号分割分别对两部分进行Base64解码得到IV字节数组和密文字节数组再用这个IV去解密。5.4 性能与数据长度考量AES加密对性能影响很小但对于特别长的数据比如一篇大文章加密解密会消耗一些CPU时间和内存。对于文本字段如手机号、身份证、地址完全不用担心。对于文件或超大报文可以考虑只加密关键部分或者评估是否真的需要应用层加密。另外加密后的数据经过Base64编码体积会比原始二进制数据增大约33%。在传输大量数据时需要考虑这点。不过对于敏感信息这点开销是值得的。6. 安全增强与最佳实践实现基础加解密只是第一步要真正安全还需要考虑更多。6.1 动态密钥与会话管理如前所述静态密钥风险较高。最佳实践是结合用户会话。流程如下用户登录服务端验证成功。服务端生成一个随机的AES会话密钥和IV每次登录都可以不同。服务端将此{sessionKey, iv}与当前用户的会话ID如Token关联存储在服务端缓存如Redis中并设置过期时间。服务端将会话密钥和IV通过HTTPS返回给小程序端。小程序端将其保存在内存或本地存储中后续所有敏感API请求都使用这对密钥进行加密。服务端收到加密请求后根据请求头中的会话ID从缓存中取出对应的密钥和IV进行解密。用户退出或会话过期服务端和客户端同时清除密钥。这样即使某一次通信的密钥被破解也不会影响其他用户或其他会话。6.2 结合HTTPS与非对称加密AES是对称加密密钥传输是个问题。我们可以用非对称加密RSA来保护对称密钥的传输。服务端生成RSA密钥对私钥保密公钥可以暴露例如通过接口下发给小程序。小程序端每次需要建立安全通信时自己生成一对随机的AES密钥和IV。小程序用RSA公钥加密这个AES密钥然后将加密后的密钥和IVIV可以不加密传给服务端。服务端用RSA私钥解密得到AES密钥。此后双方使用这个AES密钥进行对称加密通信。这种方式更安全但增加了复杂度。对于大多数小程序内网通信场景在HTTPS基础上使用动态会话密钥的AES加密已经能提供足够的安全保障。6.3 数据完整性校验加密保证了机密性但还需要防止数据在传输中被篡改。可以在加密数据之外额外计算一个签名Signature。发送方将明文数据或密文加上一个只有双方知道的“盐”salt然后计算其HMAC-SHA256值得到签名。发送方将密文和签名一起发送。接收方收到后用同样的密钥和盐对密文或解密后的明文计算HMAC与传来的签名比对。如果不一致说明数据被篡改。这确保了数据的完整性。在微信小程序中可以使用miniprogram-sm-crypto的HMAC功能Java端使用javax.crypto.Mac类来实现。7. 总结与个人体会折腾完这一套最大的感受就是“细节决定成败”。AES加解密本身不复杂但要让跨平台JS和Java的两端无缝对接必须保证每一个参数、每一步流程都严丝合缝。最开始我犯的错误就是把IV给忽略了导致两边死活对不上排查了半天才发现问题。对于中小型项目我建议采用“HTTPS 动态会话AES密钥”的方案。它在安全性和实现复杂度之间取得了很好的平衡。具体操作上一定要把密钥管理做好坚决避免硬编码。加解密工具类要封装好做好异常处理和日志记录方便后续排查问题。最后安全是一个持续的过程而不是一个一劳永逸的特性。除了加密还要关注代码混淆、防止反编译、接口防重放攻击、限流限频等各个方面。但无论如何给敏感数据加上一层应用层的AES加密无疑是向正确方向迈出的坚实一步它能让你在面对数据安全审计时更有底气也让你的用户更安心。