前后端数据加密实战：基于RSA+AES的混合加密方案设计与实现-平芜编程栈

1. 项目概述：为什么我们需要亲手构建数据加密层？

“构建安全的前后端数据加密实战教程”这个标题，听起来像是一个纯粹的技术实现问题，但它的背后，是每一个开发者都可能面临的现实困境。你可能已经部署了HTTPS，使用了最新的框架，但依然会在深夜收到安全扫描报告的告警，或者在数据审计时发现敏感信息以明文形式出现在日志里。HTTPS解决了传输过程中的“管道安全”，但数据在离开你的前端代码、抵达后端服务之前，以及在服务器内存、日志、数据库中时，它依然是“裸奔”的。

这就是我们今天要解决的问题：在应用层构建一道属于你自己的、可控的数据加密防线。这不仅仅是把一串字符变成另一串字符那么简单，它涉及到密钥的生命周期管理、加密算法的选择、性能的权衡，以及如何与现有业务逻辑无缝集成。无论是用户注册时的密码、支付时的银行卡号、还是聊天记录中的隐私内容，都需要这道额外的保护层。本教程将从一个全栈开发者的视角，带你从零开始，设计并实现一套健壮、可维护的前后端数据加密方案。我们会避开纯理论的空谈，直接进入代码和配置，分享我在多个生产项目中踩过的坑和总结出的最佳实践。

2. 整体架构设计与核心思路拆解

在动手写代码之前，我们必须先想清楚整个加密体系的蓝图。一个鲁棒的加密方案，绝不是在前端调个CryptoJS，在后端调个decrypt那么简单。它需要系统性的思考。

2.1 分层加密策略：不把鸡蛋放在一个篮子里

我的核心思路是“分层加密”和“最小化暴露”。不要试图用一种加密方式解决所有问题。

第一层：传输层加密（HTTPS）这是基石，必须要有。它确保了数据从用户浏览器到你的服务器整个网络链路上的安全，防止中间人窃听和篡改。但请记住，HTTPS保护的是“传输中”的数据。数据到达你的Nginx或应用服务器后，就会被解密。

第二层：应用层端到端加密（本教程核心）这是我们自己构建的一层。目标是：即使数据在传输过程中被截获（假设HTTPS被破解，虽然概率极低），或者在你的服务器日志、数据库中被不当查看，攻击者看到的也只是一堆无法直接理解的密文。

前端：在数据提交（如axios.post）之前，对特定的敏感字段（如password,idCard,bankAccount）进行加密。
后端：在进入业务逻辑（如Controller层）之前，先对接收到的密文进行解密，还原出原始明文，再交给Service层处理。

第三层：存储层加密对于极度敏感的数据（如医疗记录、金融密匙），在存入数据库时可以进行二次加密。这通常使用数据库提供的透明加密功能（如MySQL的AES_ENCRYPT）或在应用层使用不同的密钥进行加密。这确保了即使数据库文件被拖库，数据也不易泄露。

本教程将聚焦于第二层——应用层端到端加密，这是开发者在业务代码中最具控制力的一环。

2.2 加密模式选择：对称加密与非对称加密的权衡

该用哪种算法？这是第一个技术决策点。

对称加密（如 AES）：加密和解密使用同一把密钥。优点是速度快，适合加密大量数据。缺点是密钥如何安全地在前端和后端之间共享？把密钥硬编码在前端代码里等于没加密。
非对称加密（如 RSA）：使用公钥加密、私钥解密。前端可以持有公开的公钥进行加密，后端用绝不外泄的私钥解密。解决了密钥分发问题。缺点是速度慢，不适合加密大数据量。

我们的混合方案：结合两者优势，这是业界常见的最佳实践。

前端每次发起请求时，动态生成一个随机的“会话密钥”（比如一个16字节的随机字符串）。
前端使用后端提供的RSA公钥，对这个“会话密钥”进行加密，得到“加密的会话密钥”。
前端使用这个随机的“会话密钥”本身，采用AES算法对实际的业务数据（如JSON）进行加密，得到“加密的业务数据”。
前端将{encryptedSessionKey: ‘xxx’， encryptedData: ‘xxx’}一起发送给后端。
后端用RSA私钥解密出“会话密钥”，再用这个“会话密钥”解密出“业务数据”。

这样，我们既利用了非对称加密解决密钥分发，又利用了对称加密的高效来处理实际数据。每次请求的会话密钥都不同，安全性更高。

2.3 密钥管理：安全的心脏

密钥管理是加密系统中最脆弱的一环。私钥（RSA私钥、用于数据库加密的密钥）绝不能出现在代码仓库、前端资源或配置文件中。

后端私钥存储：应存储在环境变量、密钥管理服务（如HashiCorp Vault, AWS KMS, 阿里云KMS）或专用的硬件安全模块（HSM）中。启动应用时动态加载。
前端公钥获取：公钥可以相对安全地暴露。有两种方式：
1. 后端通过一个安全的接口（如/api/public-key）动态提供给前端。前端在初始化时获取。
2. 在构建时，将公钥作为配置文件注入前端项目，但要注意缓存和更新问题。
密钥轮换：必须制定密钥轮换策略。RSA密钥对可以每季度或每半年更换一次。更换时，需要保证新旧密钥有一段重叠期，以便处理尚未失效的旧请求。

3. 前端加密实战：从生成密钥到发送请求

让我们从前端开始，使用现代前端技术栈（以Vue3 + TypeScript为例）实现加密流程。我们会使用crypto-js和jsencrypt这两个库。

3.1 环境准备与依赖安装

首先，在你的Vue或React项目中安装必要的加密库。

npm install crypto-js jsencrypt # 或 yarn add crypto-js jsencrypt

crypto-js提供了可靠的AES加密实现，jsencrypt则专门用于处理RSA加密。请注意，在前端进行加密运算会消耗一定的CPU资源，对于性能敏感的应用，可以考虑使用Web Crypto API（原生、性能更好），但其API相对复杂。本文基于通用性更强的库进行讲解。

3.2 核心加密工具类封装

我将封装一个security.js工具模块，这是前端加密的核心。

// utils/security.js import CryptoJS from 'crypto-js'; import JSEncrypt from 'jsencrypt'; // 这是一个示例公钥，实际项目中应从后端接口动态获取 const PUBLIC_KEY = `-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1SU1LfVLPHCozMxH2Mo 4lgOEePzNm0tRgeLezV6ffAt0gunVTLw7onLRnrq0/IzW7yWR7QkrmBL7jTKEn5u ...（你的RSA公钥）... -----END PUBLIC KEY-----`; class SecurityClient { constructor() { this.rsaEncryptor = new JSEncrypt(); this.rsaEncryptor.setPublicKey(PUBLIC_KEY); } /** * 生成随机的AES会话密钥（16字节，对应AES-128） * @returns {string} 十六进制格式的密钥 */ generateAESKey() { const randomBytes = CryptoJS.lib.WordArray.random(16); // 16字节 = 128位 return CryptoJS.enc.Hex.stringify(randomBytes); } /** * 使用AES密钥加密数据 * @param {string|Object} data - 要加密的数据，对象会被转为JSON字符串 * @param {string} aesKeyHex - 十六进制格式的AES密钥 * @returns {string} Base64格式的加密结果 */ encryptWithAES(data, aesKeyHex) { const dataStr = typeof data === 'object' ? JSON.stringify(data) : String(data); const key = CryptoJS.enc.Hex.parse(aesKeyHex); // 使用CBC模式，并自动生成IV（初始化向量） const iv = CryptoJS.lib.WordArray.random(16); const encrypted = CryptoJS.AES.encrypt(dataStr, key, { iv: iv, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }); // 将IV和密文拼接在一起，方便传输。IV无需保密，但必须唯一。 const combined = iv.concat(encrypted.ciphertext); return combined.toString(CryptoJS.enc.Base64); } /** * 使用RSA公钥加密AES密钥 * @param {string} aesKeyHex - 十六进制格式的AES密钥 * @returns {string | false} Base64格式的加密结果，失败返回false */ encryptAESKeyWithRSA(aesKeyHex) { // RSA加密对输入长度有限制，需要分段或确保密钥不长于密钥长度。 // 我们的AES密钥是16字节十六进制（32字符），在合理范围内。 return this.rsaEncryptor.encrypt(aesKeyHex); } /** * 主加密方法：对业务数据进行端到端加密 * @param {Object} payload - 需要加密的业务数据对象 * @returns {Promise<{encryptedData: string, encryptedKey: string}>} 加密后的结果 */ async encryptPayload(payload) { // 1. 生成本次请求的随机AES密钥 const aesKey = this.generateAESKey(); // 2. 用AES密钥加密业务数据 const encryptedData = this.encryptWithAES(payload, aesKey); // 3. 用RSA公钥加密AES密钥 const encryptedKey = this.encryptAESKeyWithRSA(aesKey); if (!encryptedKey) { throw new Error('RSA加密失败，请检查公钥格式'); } return { encryptedData, encryptedKey }; } } // 导出单例 export default new SecurityClient();

关键细节与避坑指南：
IV（初始化向量）的重要性：AES的CBC模式必须使用一个随机且唯一的IV。相同的密钥和明文，如果使用相同的IV，会产生相同的密文，这会泄露信息。我们将IV和密文一起传输，IV本身不需要加密。
密钥长度：我们生成的是16字节（128位）的AES密钥，平衡了安全性与性能。对于更高安全要求，可以使用32字节（256位）。
错误处理：jsencrypt.encrypt可能因公钥格式错误等原因返回false，必须进行判断。
公钥管理：示例中将公钥硬编码在代码中，这并不安全，因为它难以轮换。最佳实践是在应用初始化时，从一个安全的接口（如/api/security/public-key）获取。这个接口本身可以不用加密，但最好通过HTTPS传输。

3.3 集成到网络请求层

接下来，我们需要将加密过程无缝集成到像axios这样的HTTP客户端中，使其对业务代码透明。

// utils/request.js import axios from 'axios'; import securityClient from './security'; // 创建axios实例 const service = axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }); // 请求拦截器：自动加密特定请求的数据 service.interceptors.request.use( async (config) => { // 判断哪些请求需要加密。可以通过URL、自定义标记等方式。 // 例如，我们约定请求头中包含 `X-Need-Encrypt: true` 的请求需要加密 const needEncrypt = config.headers['X-Need-Encrypt'] === 'true'; if (needEncrypt && config.data) { try { // 删除自定义头，避免发送到后端 delete config.headers['X-Need-Encrypt']; // 执行加密 const { encryptedData, encryptedKey } = await securityClient.encryptPayload(config.data); // 将加密后的数据重组为后端约定的格式 config.data = { encryptedData, // AES加密的业务数据 encryptedKey // RSA加密的AES密钥 }; // 同时，修改Content-Type，因为数据格式变成了一个对象 config.headers['Content-Type'] = 'application/json'; } catch (error) { console.error('请求数据加密失败:', error); return Promise.reject(new Error('数据加密失败，请重试')); } } return config; }, (error) => { return Promise.reject(error); } ); // 响应拦截器（解密逻辑通常在后端，前端直接处理业务响应即可） service.interceptors.response.use( (response) => { // 假设后端返回的数据已经是解密后的明文 return response.data; }, (error) => { // 统一错误处理 return Promise.reject(error); } ); export default service;

现在，在你的业务代码中，你可以这样发起一个加密请求：

import request from '@/utils/request'; export function login(data) { return request({ url: '/user/login', method: 'post', data, // 原始的明文数据，如 {username: 'admin', password: '123456'} headers: { 'X-Need-Encrypt': 'true' // 标记此请求需要加密 } }); }

对于业务开发者来说，他们感知不到加密的存在，只需要关心业务数据。所有的加密动作都在请求拦截器中自动完成。

4. 后端解密实战：Spring Boot 实现

前端把加密后的数据送过来了，后端需要安全、高效地将其解密。我们以Spring Boot（Java）为例，展示后端的解密流程。

4.1 依赖引入与密钥配置

首先，在pom.xml中添加必要的依赖。

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 用于Base64编解码 --> <dependency> <groupId>commons-codec</groupId> <artifactId>commons-codec</artifactId> </dependency> <!-- Bouncy Castle 提供丰富的加密算法支持，特别是处理PEM格式密钥 --> <dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcpkix-jdk15on</artifactId> <version>1.70</version> <!-- 使用最新稳定版 --> </dependency>

接下来，我们将私钥存储在环境变量中，并通过application.yml读取。

# application.yml security: encryption: rsa: private-key: ${RSA_PRIVATE_KEY:} # 从环境变量RSA_PRIVATE_KEY读取 aes: mode: CBC padding: PKCS5Padding # 对应前端的Pkcs7

绝对不要将私钥直接写在配置文件中提交到代码仓库。在服务器上，通过Docker的-e参数、Kubernetes的Secret或云平台的密钥管理服务来设置RSA_PRIVATE_KEY环境变量。

4.2 核心解密工具类

我们创建一个EncryptionService，负责RSA解密AES密钥，以及用AES密钥解密业务数据。

package com.yourproject.service; import lombok.extern.slf4j.Slf4j; import org.apache.commons.codec.binary.Base64; import org.bouncycastle.asn1.pkcs.PrivateKeyInfo; import org.bouncycastle.openssl.PEMParser; import org.bouncycastle.openssl.jcajce.JcaPEMKeyConverter; import org.springframework.beans.factory.annotation.Value; import org.springframework.stereotype.Service; import javax.annotation.PostConstruct; import javax.crypto.Cipher; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.io.StringReader; import java.nio.charset.StandardCharsets; import java.security.PrivateKey; @Service @Slf4j public class EncryptionService { @Value("${security.encryption.rsa.private-key}") private String rsaPrivateKeyPem; // PEM格式的私钥字符串 @Value("${security.encryption.aes.mode}") private String aesMode; @Value("${security.encryption.aes.padding}") private String aesPadding; private PrivateKey rsaPrivateKey; /** * 初始化，加载RSA私钥 */ @PostConstruct public void init() { try { // 使用Bouncy Castle解析PEM格式的私钥 PEMParser pemParser = new PEMParser(new StringReader(rsaPrivateKeyPem)); Object object = pemParser.readObject(); pemParser.close(); JcaPEMKeyConverter converter = new JcaPEMKeyConverter(); if (object instanceof PrivateKeyInfo) { this.rsaPrivateKey = converter.getPrivateKey((PrivateKeyInfo) object); } else { // 也可能是其他格式，如PKCS8EncryptedPrivateKeyInfo，需要密码解密，这里简化处理 this.rsaPrivateKey = converter.getPrivateKey((PrivateKeyInfo) object); } log.info("RSA私钥加载成功"); } catch (Exception e) { log.error("初始化RSA私钥失败", e); throw new RuntimeException("加密服务初始化失败", e); } } /** * 使用RSA私钥解密AES密钥 * @param encryptedAesKeyBase64 前端传来的、经过RSA加密并Base64编码的AES密钥 * @return 解密后的AES密钥（十六进制字符串） */ public String decryptAesKeyWithRSA(String encryptedAesKeyBase64) { try { byte[] encryptedKeyBytes = Base64.decodeBase64(encryptedAesKeyBase64); Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding"); cipher.init(Cipher.DECRYPT_MODE, rsaPrivateKey); byte[] decryptedKeyBytes = cipher.doFinal(encryptedKeyBytes); return new String(decryptedKeyBytes, StandardCharsets.UTF_8); // 返回十六进制字符串 } catch (Exception e) { log.error("RSA解密AES密钥失败", e); throw new RuntimeException("解密失败，密钥可能不正确", e); } } /** * 使用AES密钥解密业务数据 * @param encryptedDataBase64 前端传来的、经过AES加密并Base64编码的业务数据（包含IV） * @param aesKeyHex 解密后的AES密钥（十六进制字符串） * @return 解密后的原始JSON字符串 */ public String decryptDataWithAES(String encryptedDataBase64, String aesKeyHex) { try { // 1. Base64解码 byte[] combinedBytes = Base64.decodeBase64(encryptedDataBase64); // 2. 分离IV（前16字节）和实际密文 byte[] ivBytes = new byte[16]; byte[] cipherTextBytes = new byte[combinedBytes.length - 16]; System.arraycopy(combinedBytes, 0, ivBytes, 0, 16); System.arraycopy(combinedBytes, 16, cipherTextBytes, 0, cipherTextBytes.length); // 3. 准备AES密钥和IV byte[] keyBytes = hexStringToByteArray(aesKeyHex); SecretKeySpec secretKeySpec = new SecretKeySpec(keyBytes, "AES"); IvParameterSpec ivParameterSpec = new IvParameterSpec(ivBytes); // 4. 执行解密 Cipher cipher = Cipher.getInstance("AES/" + aesMode + "/" + aesPadding); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec); byte[] decryptedBytes = cipher.doFinal(cipherTextBytes); return new String(decryptedBytes, StandardCharsets.UTF_8); } catch (Exception e) { log.error("AES解密业务数据失败", e); throw new RuntimeException("数据解密失败", e); } } /** * 主解密方法：一步解密前端传来的完整加密包 * @param encryptedKey RSA加密的AES密钥 * @param encryptedData AES加密的业务数据 * @return 解密后的业务数据JSON字符串 */ public String decryptPayload(String encryptedKey, String encryptedData) { // 1. RSA解密，得到AES密钥 String aesKeyHex = decryptAesKeyWithRSA(encryptedKey); // 2. AES解密，得到业务数据明文 return decryptDataWithAES(encryptedData, aesKeyHex); } /** * 十六进制字符串转字节数组 */ private byte[] hexStringToByteArray(String s) { int len = s.length(); byte[] data = new byte[len / 2]; for (int i = 0; i < len; i += 2) { data[i / 2] = (byte) ((Character.digit(s.charAt(i), 16) << 4) + Character.digit(s.charAt(i + 1), 16)); } return data; } }

4.3 集成到Spring MVC：自定义参数解析器

为了让业务Controller像处理普通JSON一样处理加密请求，我们可以创建一个自定义的@DecryptRequestBody注解和对应的参数解析器。

首先，定义注解：

package com.yourproject.annotation; import java.lang.annotation.*; @Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface DecryptRequestBody { }

然后，实现HandlerMethodArgumentResolver：

package com.yourproject.resolver; import com.fasterxml.jackson.databind.ObjectMapper; import com.yourproject.annotation.DecryptRequestBody; import com.yourproject.service.EncryptionService; import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import org.springframework.core.MethodParameter; import org.springframework.stereotype.Component; import org.springframework.web.bind.support.WebDataBinderFactory; import org.springframework.web.context.request.NativeWebRequest; import org.springframework.web.method.support.HandlerMethodArgumentResolver; import org.springframework.web.method.support.ModelAndViewContainer; import javax.servlet.http.HttpServletRequest; import java.util.Map; @Component @RequiredArgsConstructor @Slf4j public class DecryptRequestBodyResolver implements HandlerMethodArgumentResolver { private final EncryptionService encryptionService; private final ObjectMapper objectMapper; @Override public boolean supportsParameter(MethodParameter parameter) { // 支持带有 @DecryptRequestBody 注解的参数 return parameter.hasParameterAnnotation(DecryptRequestBody.class); } @Override public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception { HttpServletRequest request = (HttpServletRequest) webRequest.getNativeRequest(); // 1. 读取请求体，期望格式：{"encryptedData": "...", "encryptedKey": "..."} String body = request.getReader().lines().reduce("", (accumulator, actual) -> accumulator + actual); if (body.isEmpty()) { throw new IllegalArgumentException("请求体为空"); } Map<String, String> encryptedPayload; try { encryptedPayload = objectMapper.readValue(body, Map.class); } catch (Exception e) { throw new IllegalArgumentException("请求体格式错误，应为JSON对象", e); } String encryptedData = encryptedPayload.get("encryptedData"); String encryptedKey = encryptedPayload.get("encryptedKey"); if (encryptedData == null || encryptedKey == null) { throw new IllegalArgumentException("请求体中必须包含 encryptedData 和 encryptedKey 字段"); } // 2. 调用解密服务解密 String decryptedJson = encryptionService.decryptPayload(encryptedKey, encryptedData); log.debug("解密后的数据: {}", decryptedJson); // 3. 将解密后的JSON字符串反序列化为目标类型 Class<?> targetType = parameter.getParameterType(); return objectMapper.readValue(decryptedJson, targetType); } }

最后，在Web配置中注册这个解析器：

package com.yourproject.config; import com.yourproject.resolver.DecryptRequestBodyResolver; import lombok.RequiredArgsConstructor; import org.springframework.context.annotation.Configuration; import org.springframework.web.method.support.HandlerMethodArgumentResolver; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; import java.util.List; @Configuration @RequiredArgsConstructor public class WebConfig implements WebMvcConfigurer { private final DecryptRequestBodyResolver decryptRequestBodyResolver; @Override public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) { resolvers.add(decryptRequestBodyResolver); } }

现在，在你的Controller中，你可以像下面这样使用：

package com.yourproject.controller; import com.yourproject.annotation.DecryptRequestBody; import com.yourproject.dto.LoginDTO; import com.yourproject.vo.Result; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @RestController @RequestMapping("/api/user") public class UserController { @PostMapping("/login") public Result login(@DecryptRequestBody LoginDTO loginDTO) { // loginDTO 已经是解密后的明文对象了！ // 例如：{username: "admin", password: "123456"} // 接下来进行正常的业务逻辑：验证用户名密码、生成Token等 System.out.println("收到登录请求，用户名：" + loginDTO.getUsername()); // ... 你的业务逻辑 return Result.success("登录成功"); } }

对于业务开发者而言，他们只需要添加一个@DecryptRequestBody注解，就能自动获得解密后的数据对象，加密解密过程被完全封装，业务代码保持干净简洁。

5. 高级话题与生产环境考量

实现基础功能只是第一步，要真正用于生产，还需要考虑更多。

5.1 性能优化与缓存策略

加密解密是CPU密集型操作，尤其是RSA解密。在高并发场景下，可能成为瓶颈。

RSA解密缓存：每次请求的AES密钥都不同，但RSA解密操作是必须的。可以考虑使用缓存（如Caffeine）来缓存encryptedKey -> aesKey的映射。如果短时间内收到相同的encryptedKey（可能由客户端重试导致），可以直接使用缓存的AES密钥，避免重复的RSA解密。但缓存时间要极短（如5秒），并且要确保密钥的唯一性。
连接复用：确保前端使用HTTP/2，并复用TCP连接，可以减少每次建立连接的开销。
异步解密：对于非实时性要求极高的场景，可以将解密任务放入线程池异步处理，快速释放Web容器的线程。

5.2 密钥轮换与向后兼容

密钥不能永远不换。轮换策略需要精心设计。

准备新密钥对：生成新的RSA密钥对。将新公钥通过安全接口提供给前端。
双密钥并行期：在后端，同时支持新旧两对私钥进行解密。这可以通过在EncryptionService中维护一个私钥列表来实现。当收到加密请求时，依次尝试用新旧私钥解密，直到成功为止。
前端平滑升级：前端应用在获取新公钥后，后续请求使用新公钥加密。对于尚未升级的客户端（如用户未刷新浏览器），它们仍使用旧公钥，后端也能解密，保证了兼容性。
淘汰旧密钥：在所有客户端都升级完毕（可通过日志监控）后，经过一个足够长的安全缓冲期，再从后端移除旧私钥的支持。

5.3 安全加固与防重放攻击

目前的方案保证了数据的机密性，但还需要完整性（Integrity）和防重放（Replay Attack）。

数据签名：前端在加密后，可以对encryptedData生成一个HMAC签名（使用另一个密钥），一并发送给后端。后端验证签名，确保数据在传输过程中未被篡改。
防重放攻击：
- 时间戳：在加密的数据包中加入当前时间戳（如timestamp）。后端收到后，检查时间戳是否在合理的时间窗口内（如±5分钟），过期则拒绝。
- Nonce：每次请求使用一个唯一的随机数（Nonce）。后端缓存近期使用过的Nonce，如果收到重复的Nonce，则判定为重放攻击，拒绝请求。Nonce可以放在加密的数据体内，或者作为一个额外的明文字段。

一个增强的请求体结构可能如下：

{ "encryptedKey": "...", "encryptedData": "...", "signature": "...", // 对encryptedData的HMAC签名 "timestamp": 1678886400000, // 明文时间戳 "nonce": "a1b2c3d4e5" // 明文随机数 }

5.4 监控、日志与调试

严禁日志明文：确保在日志中绝不打印解密前的encryptedData或解密后的敏感信息明文。使用脱敏或哈希值代替。
监控解密失败率：监控decryptPayload方法的失败次数。失败率异常升高可能意味着前端公钥版本不一致、攻击尝试或系统bug。
提供健康检查接口：提供一个/api/security/health接口，返回当前使用的公钥指纹或版本号，便于运维和客户端诊断。

6. 常见问题排查与实战技巧

在实际部署和联调中，你肯定会遇到各种问题。这里记录了一些典型的坑和解决方法。

6.1 前端加密，后端解密失败

这是联调阶段最常见的问题。

检查Base64编码：前端加密后的数据是Base64字符串吗？后端解码前是否做了URL Decode（如果传输过程中被编码了）？确保前后端使用的Base64库标准一致（通常使用URL安全的Base64，将+/替换为-_，并去掉填充=）。
检查AES参数：这是最大的坑点！
- 模式（Mode）：前后端必须一致，如CBC。
- 填充（Padding）：前后端必须一致。前端CryptoJS默认使用Pkcs7，Java对应PKCS5Padding（在AES的上下文中，PKCS5和PKCS7是等价的）。
- 密钥长度：前端生成的AES密钥是16字节（128位）还是32字节（256位）？后端的SecretKeySpec必须使用相同的长度。
- IV处理：前端是否将IV拼接到了密文前？后端是否正确地将前16字节分离出来作为IV？
检查RSA密钥格式：
- 后端加载的私钥格式是否正确？必须是PKCS#8格式的PEM文件（以-----BEGIN PRIVATE KEY-----开头）。如果是从OpenSSL生成的PKCS#1格式（以-----BEGIN RSA PRIVATE KEY-----开头），需要使用openssl pkcs8 -topk8 -nocrypt命令进行转换。
- 前端使用的公钥格式是否正确？必须是-----BEGIN PUBLIC KEY-----格式。
调试技巧：
- 在前端，将生成的aesKeyHex（明文）、encryptedData（Base64）打印到控制台（仅限调试，生产环境务必删除！）。
- 在后端，先尝试用打印出来的aesKeyHex直接解密encryptedData，跳过RSA步骤。如果成功，说明AES部分没问题，问题出在RSA解密或密钥传输上。

6.2 性能问题

现象：接口响应时间明显变长，服务器CPU使用率升高。
排查：
1. 使用性能分析工具（如Arthas）定位热点，确认是RSA解密耗时。
2. 检查是否每次请求都执行了RSA解密。如前所述，引入短期缓存。
3. 考虑升级RSA密钥长度？不，2048位是目前安全与性能的平衡点，升级到4096位会显著增加解密时间。更好的办法是评估是否所有数据都需要如此高强度的加密，可以对数据进行分级。

6.3 在特定框架中的集成

在Nuxt.js/Next.js（SSR）中：注意加密库是否支持服务端渲染。crypto-js和jsencrypt都依赖于浏览器环境的window对象。在服务端，需要使用Node.js内置的crypto模块进行替代实现，或者通过动态导入（import(‘jsencrypt’).then(...)）避免在服务端打包。
在微信小程序中：小程序环境没有window对象，且对CryptoJS的某些依赖（如Buffer）支持不完整。推荐使用小程序官方提供的WX-Secure网络通道，或寻找专门为小程序编译的加密库。
与API网关集成：如果你的架构中有API网关（如Kong, APISIX），可以考虑将解密逻辑下沉到网关层。这样，业务服务接收到的直接就是明文数据，无需每个服务都集成解密代码。但这增加了网关的复杂性和耦合度，需要权衡。

6.4 一个被我忽略的“小”问题：JSON序列化

有一次在排查问题时发现，前端加密的对象和后端解密后反序列化的对象，个别字段值对不上。最后发现是浮点数精度问题。前端JavaScript的JSON.stringify对某些浮点数的序列化，与后端Jackson的反序列化，可能产生极细微的差异。虽然对于大多数业务场景不影响，但如果这个字段被用于加密前的哈希或签名，就会导致校验失败。

解决方案：对于涉及加密、签名的数据，在序列化时指定一个确定的、无损的格式。例如，在前端使用JSON.stringify时，可以传入一个replacer函数，将数字强制转换为字符串。或者，更推荐的是，在加密前，先将业务数据对象转换成一个确定的字符串格式，例如按字段名排序后拼接成键值对。