Spring Boot中统一加解密应使用RequestBodyAdvice和ResponseBodyAdvice实现全局透明处理，支持注解控制开关、AES-256-GCM加密、动态密钥管理及签名验证。
在 Spring Boot 中实现统一的接口加密与解密传输，核心思路是**在请求进入 Controller 前自动解密，在响应返回客户端前自动加密**。不建议在每个 Controller 方法里手动加解密，而应借助 Spring 的拦截器（HandlerInterceptor）或 WebMvcConfigurer 配合 @ControllerAdvice + ResponseBodyAdvice/RequestBodyAdvice 实现全局、透明的处理。
使用 RequestBodyAdvice 和 ResponseBodyAdvice（推荐）
这是最契合 RESTful 场景的方式，能精准作用于 @RequestBody 和 @ResponseBody，且天然支持泛型和消息转换器（如 Jackson），不影响原有逻辑。
关键点：
- 自定义类实现
RequestBodyAdvice，重写supports()和beforeBodyRead()：在 Jackson 反序列化前，先对原始字节流/字符串做解密（如 AES 解密），再交给 Jackson 解析 - 自定义类实现
ResponseBodyAdvice，重写supports()和beforeBodyWrite()：在 Jackson 序列化后、写入响应体前，对 JSON 字符串整体加密（如 AES 加密），并可包装成标准格式（如{"code":0,"data":"xxx","msg":"ok"}） - 注意 Content-Type：通常约定客户端传
application/encrypted+json，服务端返回同类型；或统一用application/json，靠约定字段（如encrypt=true）判断是否启用加解密 - 密钥管理：避免硬编码，可用
@Value("${app.crypto.key}")从配置读取，生产环境建议结合 KMS 或配置中心动态获取
配合自定义注解控制开关
不是所有接口都需要加解密（如登录、健康检查）。可通过自定义注解（如 @NeedCrypto）标记需要加解密的 Controller 或方法。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
做法：
- 在
supports()方法中检查当前请求对应的方法/类是否有该注解，有则启用加解密，否则跳过 - 注解可设属性如
algorithm = "AES/GCM/PKCS5Padding"，支持不同算法灵活切换 - 避免对文件上传（
MultipartFile）、流式响应等非 JSON 场景误触发
加解密算法与安全细节
别只用简单 Base64——它不是加密。生产环境必须用强加密算法：
-
AES-256-GCM：推荐，带认证加密，防篡改，Java 8u191+ 原生支持；需生成随机 IV 并随密文一起传输（如 Base64 合并为
iv.ciphertext） - 密钥派生：若用密码（password）而非原始密钥，应通过
PBKDF2WithHmacSHA256+ salt 派生，不可直接当 AES 密钥 - 签名验证（可选增强）：在加密前对明文 JSON 计算 HMAC-SHA256，连同密文一并返回，客户端解密后校验签名，防止中间人篡改密文
- 避免常见坑：AES ECB 模式（不安全）、固定 IV、密钥重复使用、未验证填充（PKCS#5/7）
客户端和服务端约定示例
前后端需明确协议，例如：
- 请求头：
X-Crypto: AES-GCM表示启用加密；X-Nonce: base64(iv)传递初始化向量 - 请求体：原始 JSON 经 AES-GCM 加密后，Base64 编码的字符串
- 响应体：JSON 加密后，返回统一结构：
{"code":200,"data":"base64(encrypted_json)","timestamp":171...,"sign":"hmac..."} - 异常处理：加解密失败时，
RequestBodyAdvice抛出HttpMessageNotReadableException，由全局异常处理器返回 400 错误，不泄露密钥相关细节
