1. 项目概述：为什么前后端都需要AES加解密？

在前后端分离架构成为主流的今天，数据在网络上“裸奔”的风险比以往任何时候都高。无论是用户登录的密码、个人身份信息，还是交易数据，一旦在传输过程中被截获，后果不堪设想。因此，在前后端之间建立一个可靠的数据加密通道，是每个合格开发者必须考虑的安全基线。

AES（Advanced Encryption Standard，高级加密标准）作为一种对称加密算法，因其安全性高、性能好、被广泛支持，成为了这个场景下的首选。所谓“对称”，意味着加密和解密使用同一把密钥。这就像你和通信方共享一把唯一的钥匙，你用这把钥匙锁上箱子（加密），对方用同一把钥匙打开箱子（解密）。这个项目要解决的，就是如何在Java后端和各类前端（如Vue、React、原生JavaScript）之间，协同使用这把“钥匙”，确保数据在传输过程中的机密性。

这不仅仅是调用一个API那么简单。在实际项目中，我遇到过前端加密了后端解不开、双方密钥不一致导致生产环境瘫痪、或者因为编码问题导致密文传输后乱码等情况。本文将从一个全栈开发者的视角，拆解前后端协同实现AES加解密的完整方案，涵盖核心原理、标准实现、避坑指南以及那些在官方文档里不会写的实战经验。

2. AES加解密核心原理与模式选择

在动手写代码之前，我们必须对AES的基本工作原理和关键参数有清晰的认识，这是避免后续各种“灵异事件”的基础。

2.1 对称加密的核心：密钥与分组

AES是一种分组加密算法，它会把明文数据切分成固定长度的“块”（Block）进行处理。AES的块大小固定为128位（即16字节）。这意味着，无论你的原始数据是1个字节还是100个字节，在加密时都会被组织成若干个16字节的块。

密钥则是加密和解密的灵魂。AES支持三种密钥长度：128位、192位和256位。密钥越长，安全性理论上越高，但计算开销也会略微增加。对于绝大多数前后端传输加密场景，128位密钥已完全足够，它能在安全性和性能之间取得很好的平衡。256位密钥则常用于对安全性要求极高的场景，如金融系统。

注意：密钥长度直接决定了加密的强度，但更重要的是密钥本身的随机性和保密性。使用“123456”或项目名作为密钥，即使用256位也是徒劳。

2.2 工作模式与填充：ECB、CBC与PKCS5Padding

仅仅有密钥和分组还不够，我们还需要决定如何对多个数据块进行加密，以及当最后一个数据块不足16字节时如何处理。这就是工作模式和填充模式。

1. 工作模式（Mode）

• ECB（Electronic Codebook，电子密码本模式） ：最简单的模式，每个数据块独立加密。致命缺点是，相同的明文块会被加密成相同的密文块。对于有规律的数据（如图像），会在密文中留下明文的模式，安全性很差。 在前后端传输中，应绝对避免使用ECB模式。
• CBC（Cipher Block Chaining，密码分组链接模式） ：这是最常用、推荐默认使用的模式。它引入了一个“初始化向量”（IV， Initialization Vector）。每个明文块在加密前，会先与前一个密文块进行异或操作（第一个块与IV异或）。这样，即使明文相同，只要IV不同，产生的密文就完全不同，有效隐藏了数据模式。 IV不需要保密，但必须随机且唯一，通常随密文一起传输给解密方。

2. 填充模式（Padding） 因为数据长度不总是16字节的整数倍，需要对最后一个块进行填充。PKCS5Padding（或PKCS7Padding，在AES语境下两者等价）是最通用的填充方式。它会在数据末尾添加N个字节，每个字节的值都是N。例如，如果最后缺5个字节，就填充 0x05 0x05 0x05 0x05 0x05 。解密端会根据最后一个字节的值，移除相应数量的填充字节。

3. 字符编码与二进制数据 这是前后端联调中最容易踩坑的地方。AES加密操作的对象是二进制字节数组（byte[]）。而我们在前后端传输时，通常使用文本格式（如JSON）。因此，必须将加密后的二进制字节数组，转换为一种文本形式的编码。Base64编码是标准做法，它能将任意二进制数据转换成由A-Z、a-z、0-9、+、/组成的ASCII字符串，便于在JSON、URL中安全传输。

所以，一个完整的前后端AES加解密流程通常约定为： AES/CBC/PKCS5Padding ，密钥长度128/256位，输出使用Base64编码。

3. Java后端实现详解

后端的实现通常更规范，我们以Spring Boot项目为例，创建一个可复用的加解密工具类。

3.1 核心工具类构建

首先，在 pom.xml 中确保有相关的依赖（Spring Boot通常已包含）：

<!-- Spring Boot Web项目已包含所需JCA（Java密码体系结构）支持 -->

然后，创建工具类 AesUtil.java ：

import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.nio.charset.StandardCharsets;
import java.util.Base64;

public class AesUtil {
    // 算法/模式/填充
    private static final String ALGORITHM = "AES/CBC/PKCS5Padding";
    // 密钥算法
    private static final String KEY_ALGORITHM = "AES";
    // 默认字符集
    private static final String CHARSET = "UTF-8";

    /**
     * AES加密
     * @param content 明文
     * @param key 密钥（必须为16/24/32字节，对应128/192/256位）
     * @param iv 初始化向量（必须为16字节）
     * @return Base64编码的密文
     */
    public static String encrypt(String content, String key, String iv) throws Exception {
        // 参数校验
        if (key == null || key.length() != 16) {
            throw new RuntimeException("密钥长度必须为16字节（128位）");
        }
        if (iv == null || iv.length() != 16) {
            throw new RuntimeException("初始化向量IV长度必须为16字节");
        }

        // 1. 创建Cipher实例，指定算法
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        // 2. 根据密钥字节数组创建SecretKeySpec
        SecretKeySpec secretKeySpec = new SecretKeySpec(key.getBytes(CHARSET), KEY_ALGORITHM);
        // 3. 创建IvParameterSpec
        IvParameterSpec ivParameterSpec = new IvParameterSpec(iv.getBytes(CHARSET));
        // 4. 初始化Cipher为加密模式
        cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec);
        // 5. 执行加密，得到二进制字节数组
        byte[] encryptedBytes = cipher.doFinal(content.getBytes(CHARSET));
        // 6. 将二进制密文转换为Base64字符串，便于传输
        return Base64.getEncoder().encodeToString(encryptedBytes);
    }

    /**
     * AES解密
     * @param content Base64编码的密文
     * @param key 密钥（必须为16/24/32字节）
     * @param iv 初始化向量（必须为16字节）
     * @return 明文
     */
    public static String decrypt(String content, String key, String iv) throws Exception {
        // 参数校验
        if (key == null || key.length() != 16) {
            throw new RuntimeException("密钥长度必须为16字节（128位）");
        }
        if (iv == null || iv.length() != 16) {
            throw new RuntimeException("初始化向量IV长度必须为16字节");
        }

        Cipher cipher = Cipher.getInstance(ALGORITHM);
        SecretKeySpec secretKeySpec = new SecretKeySpec(key.getBytes(CHARSET), KEY_ALGORITHM);
        IvParameterSpec ivParameterSpec = new IvParameterSpec(iv.getBytes(CHARSET));
        // 初始化解密模式
        cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec);
        // 先将Base64字符串解码为二进制字节数组，再进行解密
        byte[] decryptedBytes = cipher.doFinal(Base64.getDecoder().decode(content));
        return new String(decryptedBytes, CHARSET);
    }
}

3.2 密钥与IV的管理策略

密钥和IV的安全管理是加密系统的命门。绝对不要将硬编码在源代码中并提交到代码仓库。

1. 配置化管理 将密钥和IV放在配置文件中（如 application.yml ），并在生产环境通过环境变量注入。

# application.yml
aes:
  key: “Your16ByteKeyStr” # 实际应为16个字符的字符串
  iv: “Your16ByteIvStr“ # 实际应为16个字符的字符串

在工具类或Service中通过 @Value 注入。对于生产环境，密钥应从安全的配置中心或KMS（密钥管理服务）获取。

2. 动态IV生成 对于CBC模式，每次加密使用随机IV是更安全的做法。可以将IV和密文一起返回给前端，前端解密时需先分离IV和密文。

public static Map<String, String> encryptWithRandomIv(String content, String key) throws Exception {
    // 生成一个16字节的随机IV
    SecureRandom random = new SecureRandom();
    byte[] ivBytes = new byte[16];
    random.nextBytes(ivBytes);
    String iv = Base64.getEncoder().encodeToString(ivBytes); // 存储和传输时也转为Base64

    // 使用生成的IV进行加密
    Cipher cipher = Cipher.getInstance(ALGORITHM);
    SecretKeySpec secretKeySpec = new SecretKeySpec(key.getBytes(CHARSET), KEY_ALGORITHM);
    IvParameterSpec ivParameterSpec = new IvParameterSpec(ivBytes);
    cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec);
    byte[] encryptedBytes = cipher.doFinal(content.getBytes(CHARSET));
    String encryptedText = Base64.getEncoder().encodeToString(encryptedBytes);

    // 返回IV和密文
    Map<String, String> result = new HashMap<>();
    result.put(“iv”, iv);
    result.put(“data”, encryptedText);
    return result;
}

前端在解密时，需要先使用Base64解码收到的IV字符串，还原为二进制IV，再进行解密。

4. 前端实现详解（以JavaScript/Vue为例）

前端加密库的选择很多，但为了与后端Java完美兼容，我们必须确保使用相同的算法、模式、填充和编码方式。

4.1 使用CryptoJS库

CryptoJS是前端最常用的加密库之一。首先，通过npm安装或在HTML中引入。

npm install crypto-js

在Vue组件或普通JS模块中使用：

import CryptoJS from ‘crypto-js’;

// 定义与后端一致的密钥和IV（注意：这里是字符串，长度需为16）
const key = ‘Your16ByteKeyStr‘;
const iv = ‘Your16ByteIvStr’;

/**
 * AES加密 (CBC模式, Pkcs7填充)
 * @param {string} plainText 明文
 * @returns {string} Base64格式的密文
 */
function encrypt(plainText) {
  // 将字符串密钥和IV转换为CryptoJS需要的WordArray格式
  const keyWordArray = CryptoJS.enc.Utf8.parse(key);
  const ivWordArray = CryptoJS.enc.Utf8.parse(iv);

  // 执行加密
  const encrypted = CryptoJS.AES.encrypt(plainText, keyWordArray, {
    iv: ivWordArray,
    mode: CryptoJS.mode.CBC,
    padding: CryptoJS.pad.Pkcs7 // 注意：CryptoJS中叫Pkcs7，与Java的PKCS5Padding兼容
  });

  // 将加密对象转换为Base64字符串
  return encrypted.toString();
}

/**
 * AES解密
 * @param {string} cipherText Base64格式的密文
 * @returns {string} 明文
 */
function decrypt(cipherText) {
  const keyWordArray = CryptoJS.enc.Utf8.parse(key);
  const ivWordArray = CryptoJS.enc.Utf8.parse(iv);

  const decrypted = CryptoJS.AES.decrypt(cipherText, keyWordArray, {
    iv: ivWordArray,
    mode: CryptoJS.mode.CBC,
    padding: CryptoJS.pad.Pkcs7
  });

  // 将解密后的WordArray转换为UTF-8字符串
  return decrypted.toString(CryptoJS.enc.Utf8);
}

// 使用示例
const originalText = ‘{“username”: “admin”, “password”: “123456”}’;
console.log(‘明文：‘, originalText);

const encryptedText = encrypt(originalText);
console.log(‘加密后（Base64）：‘, encryptedText);

const decryptedText = decrypt(encryptedText);
console.log(‘解密后：‘, decryptedText);

4.2 处理动态IV的场景

如果后端采用每次加密随机生成IV的方式，前端接收到的数据将包含 iv 和 data 两个字段。前端解密时需要先处理IV。

/**
 * 解密（后端返回包含iv和data的对象）
 * @param {string} encryptedData 后端返回的整个加密响应体（JSON字符串）
 */
function decryptWithDynamicIv(encryptedData) {
  const dataObj = JSON.parse(encryptedData);
  const receivedIvBase64 = dataObj.iv; // Base64编码的IV
  const receivedCipherText = dataObj.data; // Base64编码的密文

  // 将Base64格式的IV转换为CryptoJS可识别的WordArray
  const ivWordArray = CryptoJS.enc.Base64.parse(receivedIvBase64);
  const keyWordArray = CryptoJS.enc.Utf8.parse(key);

  const decrypted = CryptoJS.AES.decrypt(receivedCipherText, keyWordArray, {
    iv: ivWordArray,
    mode: CryptoJS.mode.CBC,
    padding: CryptoJS.pad.Pkcs7
  });

  return decrypted.toString(CryptoJS.enc.Utf8);
}

4.3 在Axios请求拦截器中的应用

在实际项目中，我们通常不会手动调用加解密，而是通过请求/响应拦截器自动处理。以下是一个对请求体进行加密的Axios拦截器示例：

import axios from ‘axios’;
import CryptoJS from ‘crypto-js’;

const service = axios.create({
  baseURL: process.env.VUE_APP_BASE_API,
  timeout: 5000
});

// 请求拦截器：对特定请求的data进行加密
service.interceptors.request.use(
  config => {
    // 假设我们只对POST/PUT请求且content-type为json的数据进行加密
    if ((config.method === ‘post’ || config.method === ‘put’) && config.data) {
      const plainText = JSON.stringify(config.data);
      config.data = {
        encryptedData: encrypt(plainText) // 使用前面定义的encrypt函数
      };
      // 可能需要修改Content-Type，根据后端接口约定
      config.headers[‘Content-Type’] = ‘application/json’;
    }
    return config;
  },
  error => {
    return Promise.reject(error);
  }
);

// 响应拦截器：对返回的加密数据进行解密
service.interceptors.response.use(
  response => {
    const res = response.data;
    // 假设后端统一返回 { success: true, encryptedData: ‘...‘ } 的结构
    if (res.success && res.encryptedData) {
      try {
        const decryptedStr = decrypt(res.encryptedData);
        response.data = JSON.parse(decryptedStr);
      } catch (e) {
        console.error(‘响应解密失败：‘, e);
        return Promise.reject(new Error(‘数据解密错误’));
      }
    }
    return response;
  },
  error => {
    return Promise.reject(error);
  }
);

export default service;

5. 前后端联调核心：确保参数完全一致

联调阶段是问题高发区，90%的问题都源于前后端参数配置不一致。请严格按照以下清单进行核对。

5.1 参数一致性核对表

参数项	Java后端	JavaScript前端 (CryptoJS)	必须一致
算法/模式/填充	AES/CBC/PKCS5Padding	mode: CBC, padding: Pkcs7	是
密钥长度	128位 (16字节字符串)	128位 (16字符字符串)	是
密钥字符串	“1234567890123456”	‘1234567890123456’	是 (字符和顺序)
IV长度	16字节字符串	16字符字符串	是
IV字符串	“abcdefghijklmnop”	‘abcdefghijklmnop’	是 (字符和顺序)
字符编码	UTF-8	CryptoJS.enc.Utf8	是
密文输出格式	Base64	Base64 ( encrypted.toString() )	是
密文输入格式	Base64	Base64 (直接传入 decrypt )	是

5.2 联调自测步骤

1. 固定数据测试 ：前后端分别使用相同的密钥、IV和明文（如字符串 “Hello, AES!” ），各自进行加密。将加密后的Base64字符串打印出来对比，必须 完全一致 。这是验证基础算法和参数是否匹配的黄金标准。
2. 交叉解密测试 ：前端用固定参数加密一段数据，将密文发给后端解密，看是否能还原。反之亦然。
3. 引入随机性 ：测试加密包含中文、特殊符号（如 @#$% ）和较长文本的数据，确保编码无误。
4. 网络传输测试 ：在拦截器中加入加密逻辑，发起真实请求，查看浏览器Network面板中发送的数据是否为加密后的Base64字符串，并确认后端能正确解密并处理。

6. 常见问题排查与实战心得

即使参数核对一致，在实际开发中仍会遇到各种问题。下面是我从多次踩坑中总结出来的经验。

6.1 典型错误与解决方案

问题现象	可能原因	排查步骤与解决方案
后端解密失败： javax.crypto.BadPaddingException: Given final block not properly padded	1. 前后端密钥/IV不一致。 2. 前端传回的密文Base64格式错误或传输中被修改（如URL编码问题）。 3. 加密模式或填充方式不一致。	1. 打印对比 ：在前后端分别打印用于加解密的密钥和IV的 字节数组 （ key.getBytes(“UTF-8”) ），确保每个字节都相同。 2. 检查密文 ：后端收到密文后，先打印出来，与前端发送的对比。注意 + 、 / 、 = 等Base64字符在URL传输中可能被编码，建议使用URL安全的Base64编码（如 Base64.getUrlEncoder() ）或在传输前对密文进行URL编码。
前端解密失败，得到空字符串或乱码	1. 后端返回的密文不是标准的Base64字符串。 2. 前端解密时没有正确指定输出编码（ toString(CryptoJS.enc.Utf8) ）。 3. 后端加密时可能对原始数据进行了多重编码。	1. 检查后端输出 ：确保后端加密后直接对字节数组做Base64编码，不要额外做其他编码或放入复杂对象未正确序列化。 2. 前端调试 ： console.log 解密对象 decrypted ，查看其 sigBytes 属性（有效字节数）和 words 数组，确认解密是否真的产生了数据。再用正确的编码转字符串。
加解密中文出现乱码	前后端字符编码不统一，没有全部使用UTF-8。	1. Java端： String.getBytes(“UTF-8”) 和 new String(bytes, “UTF-8”) 。 2. JS端： CryptoJS.enc.Utf8.parse() 和 toString(CryptoJS.enc.Utf8) 。 3. 确保HTTP请求/响应头也设置了 Content-Type: application/json; charset=UTF-8 。
密钥长度错误导致 InvalidKeyException	密钥字符串的字节长度不是16/24/32。	使用 key.getBytes(“UTF-8”).length 检查字节长度，而不是字符串的字符长度。一个中文字符在UTF-8下占3个字节。 务必使用英文字母和数字组合作为密钥 。
使用随机IV时，每次加密结果不同，但解密正常	这是CBC模式配合随机IV的 正常现象 ，正是安全性所在。	无需处理。确保解密时使用的是加密时生成的那个IV（通常随密文一起传输）。

6.2 安全增强与性能考量

1. HTTPS是基础，加密是补充 ：务必明确，AES对请求体/响应体的加密， 不能替代HTTPS 。HTTPS（TLS）提供了传输层的安全，包括防窃听、防篡改和身份认证。本文讨论的应用层AES加密，主要用于在HTTPS基础上，对敏感业务数据（如密码、身份证号）进行二次加密，防止在服务器内部日志、中间代理等环节泄露。
2. 密钥不能前端硬编码 ：上述示例为演示方便将密钥写在前端代码中，这在实际生产环境中是 极度危险 的，因为密钥会暴露给所有用户。更安全的做法是：
   • 动态密钥交换 ：在用户登录后，由后端生成一个临时的会话密钥（Session Key），通过HTTPS通道安全地传给前端（或利用非对称加密如RSA来加密传输这个对称密钥）。本次会话后续的通信都用这个临时密钥加密。
   • 仅加密核心字段 ：并非所有数据都需要加密。可以只对密码、支付信息等极端敏感的字段进行加密，其他字段明文传输。这能减少性能开销。
3. 性能影响 ：AES加密解密是CPU密集型操作。对于大量数据或高并发场景，需评估性能损耗。在Node.js后端或客户端，加密大量数据可能引起界面卡顿，考虑使用Web Worker在后台线程进行加密操作。
4. IV的随机性 ：CBC模式下的IV必须是随机且不可预测的。在Java中，务必使用 SecureRandom ，而不是普通的 Random 。每次加密都应使用新的IV。

6.3 一个更工程化的封装建议

对于企业级项目，建议在后端将加解密能力封装成Spring Boot Starter或公共组件，并通过配置中心管理密钥。提供统一的注解或工具类，让业务开发人员无需关心细节。

// 示例：使用注解自动解密请求体
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface DecryptBody {
}

// 在Controller中使用
@PostMapping(“/user“)
public ResponseEntity createUser(@DecryptBody @Valid UserDTO userDTO) {
    // userDTO已是解密后的对象
    return ResponseEntity.ok(userService.create(userDTO));
}

实现这个注解需要自定义一个 HandlerMethodArgumentResolver ，在参数解析阶段调用统一的解密工具进行解密。

7. 总结与扩展思考

走到这里，一套完整的前后端AES加解密方案已经搭建完毕。从原理理解、代码实现、联调对接到安全加固，每一步都充满了细节。我个人的体会是，加密功能的联调成功不是终点，而是一个起点。它迫使开发团队去建立更严谨的配置管理规范，去思考密钥的生命周期，去关注日志中是否不小心打印了敏感数据。

最后分享一个小技巧：在项目初期，可以开启一个“加解密调试模式”，在请求头和响应头中附带一个标志，让后端同时处理明文和密文两套数据，并在日志中对比输出。这能极大降低联调初期的排查难度，等稳定后再关闭明文通道。另外，对于某些特定场景，比如需要让密文在URL中安全传递，记得使用URL安全的Base64编码（将 + 和 / 替换为 - 和 _ ，并去掉填充符 = ），避免特殊字符被错误解析。加密的世界很深，但从AES CBC这个坚实的起点出发，足以应对大多数前后端数据传输的安全需求了。