Spring Boot集成国密SM4：基于过滤器的全局加解密方案详解

1. 项目概述

最近在做一个金融行业的项目，对接方要求所有API交互的数据都必须使用国密SM4算法进行加密传输。这其实挺常见的，现在很多涉及敏感数据，尤其是金融、政务领域的系统，为了满足国家信息安全等级保护（等保）的要求，都会强制使用国密算法。SM4作为国家密码管理局认定的商用密码标准，其地位类似于国际上的AES，但它是我们自己的算法标准。

在Spring Boot项目里集成SM4，听起来好像就是加个依赖、写个工具类的事，但真做起来你会发现坑不少。比如，你是选择在业务代码里手动加解密，还是通过过滤器/拦截器自动处理？密钥和IV怎么管理才安全？请求体只能读一次的问题怎么解决？性能开销大不大？这些问题如果不提前想清楚，上线后可能就是一堆麻烦。

我这次选择的是基于过滤器的全局加解密方案。核心思路是：在请求到达Controller之前，通过过滤器自动解密请求体；在响应返回客户端之前，再自动加密响应体。这样，业务代码完全不用关心加解密的细节，就像处理普通明文请求一样，开发体验最好。下面我就把这次从零搭建、踩坑、优化的全过程详细拆解一遍，特别是那些文档里不会写的细节和注意事项。

2. 核心设计思路与方案选型

2.1 为什么选择过滤器方案？

在Spring Boot中处理全局加解密，常见的有三种思路：AOP切面、拦截器（Interceptor）和过滤器（Filter）。我最终选择了过滤器，主要是基于以下几个考量：

首先，从执行时机上看，Filter是Servlet层面的组件，它的执行顺序在所有Spring MVC组件（包括Interceptor和Controller）之前。这意味着当请求体流过Filter时，Spring还没有开始解析@RequestBody。我们可以在解析发生前，就把加密的请求体解密好，并“替换”掉原始的InputStream。这样，后续的HttpMessageConverter（比如处理JSON的MappingJackson2HttpMessageConverter）读到的就已经是明文了，业务Controller拿到的参数自然也是解密后的对象。这个时机是最早、最彻底的。

其次，拦截器虽然也能拿到HttpServletRequest，但它已经处于Spring MVC的上下文中了。此时，请求体可能已经被读取或部分读取，再去修改请求体内容会非常棘手，容易引发IllegalStateException（请求流已被关闭）。而AOP切面通常作用于Service层方法，粒度太细，无法处理HTTP传输层的数据，并且无法处理响应体的加密。

最后，过滤器的设计本身就是用来对请求和响应进行预处理和后处理的，这与加解密的场景完美匹配。我们可以轻松地在doFilter方法中，先解密请求，放行链，最后再加密响应，形成一个完整的处理闭环。

2.2 SM4算法模式与填充的选择

SM4是一个分组密码算法，和AES类似，它需要确定使用哪种模式（Mode）和填充（Padding）。模式决定了如何对多个数据块进行加密，填充则解决了最后一个数据块不足128位（16字节）的问题。

模式选择：CBC（密码分组链接）我选择了CBC模式，而不是ECB。ECB模式是最简单的，它直接将明文分组，独立加密。这会导致一个严重问题：相同的明文块会产生相同的密文块。如果传输的数据有规律（比如JSON结构固定），攻击者即使不知道密钥，也能从密文中看出模式，存在安全隐患。CBC模式则通过引入一个初始化向量（IV），并将前一个密文块与当前明文块进行异或操作后再加密，使得每个密文块都依赖于之前所有的块。这样，即使原文相同，只要IV不同，加密结果就完全不同，安全性高得多。这是目前最常用、也推荐使用的模式。

填充选择：PKCS7PaddingBouncy Castle库的PaddedBufferedBlockCipher默认使用的是PKCS7填充。它的规则很简单：如果需要填充N个字节，那么每个填充字节的值就是N。例如，如果最后一个块差3个字节，那么就填充0x03 0x03 0x03。解密时，查看最后一个字节的值，就知道填充了多少字节，可以准确移除。这种填充方式通用且可靠。

密钥与IV的管理这里是一个至关重要的安全实践点。示例代码里把密钥和IV硬编码在工具类中，这是绝对不可取的。一旦代码泄露，安全形同虚设。正确的做法是：

1. 环境变量/配置中心：将密钥和IV放在应用启动参数、环境变量或配置中心（如Nacos, Apollo）中。这是最基本的要求。
2. 密钥管理系统（KMS）：对于高安全要求的系统，应该使用专业的KMS来生成、存储和轮换密钥，应用在运行时动态向KMS请求密钥，内存中不长期保存。
3. IV的生成：CBC模式要求每次加密使用不同的IV，且IV不需要保密（但不可预测）。通常可以随机生成一个16字节的IV，并将其和密文一起传输（通常拼接在密文前面）。解密方先取出前16字节作为IV，再用后面的部分解密。这样能保证每次加密结果都不同。

在本文的示例中，为了聚焦于Spring集成本身，我们暂时使用配置化的方式，但你必须清楚，在生产环境中必须采用上述更安全的方式。

3. 核心工具类实现与详解

3.1 依赖引入与Bouncy Castle库

SM4算法在Java标准库中没有提供实现，我们需要借助第三方密码学提供者。Bouncy Castle（BC）是一个强大的、开源的密码学库，提供了包括国密算法（SM2, SM3, SM4）在内的广泛支持。

<dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk18on</artifactId> <version>1.78.1</version> </dependency>

版本选择注意事项：

• bcprov-jdk15on：支持JDK 1.5到1.8。后缀“on”表示“旧版本的新实现”，是一个向后兼容的版本。
• bcprov-jdk18on：专为JDK 1.8及以上版本设计。它通常包含最新的安全修复和性能优化，并可能利用了新版JDK的特性。如果你的项目使用的是JDK 8或更高版本，强烈建议使用此版本。

引入依赖后，通常不需要显式地在代码中注册Security.addProvider(new BouncyCastleProvider())，因为Bouncy Castle的JAR包通过SPI（Service Provider Interface）机制自动注册了提供者。但在某些极端情况下，如果发现算法找不到，可以手动注册一下。

3.2 SM4工具类（Sm4Util）深度解析

工具类是整个加解密的核心，我们来逐行分析其实现和背后的原理。

import org.bouncycastle.crypto.engines.SM4Engine; import org.bouncycastle.crypto.modes.CBCBlockCipher; import org.bouncycastle.crypto.paddings.PaddedBufferedBlockCipher; import org.bouncycastle.crypto.params.KeyParameter; import org.bouncycastle.crypto.params.ParametersWithIV; import java.util.Base64; public class Sm4Util { // 警告：以下仅为示例，生产环境必须从安全配置源获取！ private static final String KEY = "0123456789abcdef"; // 16字节 private static final String IV = "fedcba9876543210"; // 16字节，已修正为16位 public static String encrypt(String plainText) throws Exception { // 1. 创建密码器 PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(new SM4Engine())); // 2. 初始化（true表示加密模式） cipher.init(true, new ParametersWithIV(new KeyParameter(KEY.getBytes("UTF-8")), IV.getBytes("UTF-8"))); // 3. 准备输入输出缓冲区 byte[] input = plainText.getBytes("UTF-8"); byte[] output = new byte[cipher.getOutputSize(input.length)]; // 4. 分步处理数据 int length1 = cipher.processBytes(input, 0, input.length, output, 0); int length2 = cipher.doFinal(output, length1); // 5. 编码并返回 byte[] encryptedBytes = new byte[length1 + length2]; System.arraycopy(output, 0, encryptedBytes, 0, length1 + length2); return Base64.getEncoder().encodeToString(encryptedBytes); } public static String decrypt(String encryptedText) throws Exception { PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(new SM4Engine())); // false表示解密模式 cipher.init(false, new ParametersWithIV(new KeyParameter(KEY.getBytes("UTF-8")), IV.getBytes("UTF-8"))); byte[] input = Base64.getDecoder().decode(encryptedText); byte[] output = new byte[cipher.getOutputSize(input.length)]; int length1 = cipher.processBytes(input, 0, input.length, output, 0); int length2 = cipher.doFinal(output, length1); return new String(output, 0, length1 + length2, "UTF-8"); } }

关键点解析与避坑指南：

1. 字符编码一致性：这是最容易出错的地方之一。String.getBytes()和new String(byte[])如果不指定编码，会使用平台默认编码（如GBK）。这可能导致在加密端和解密端（可能是不同操作系统、不同环境）因编码不同而产生乱码，导致解密失败。务必显式指定UTF-8编码，确保二进制数据转换的一致性。

2. IV的长度：在CBC模式下，IV的长度必须等于分组大小，即16字节。我修正了示例中的IV为"fedcba9876543210"（16个字符）。一个常见的错误是IV长度不对，这会直接导致ParametersWithIV初始化失败。

3. processBytes与doFinal：这是分组密码处理的典型流程。processBytes可以多次调用，用于处理流式数据。doFinal执行最后的加密或解密操作，并处理填充。对于一次性处理完的数据，这样调用是标准做法。

4. 输出缓冲区大小：cipher.getOutputSize(input.length)会计算输出缓冲区的最大可能大小（考虑填充）。processBytes和doFinal返回的是实际写入的字节数。最后我们需要根据实际长度（length1 + length2）来截取有效的密文或明文字节数组，而不是直接使用整个output数组。直接使用整个数组可能会在末尾包含未初始化的数据或旧的残留数据，导致Base64编码异常或解密后字符串末尾有乱码。

5. Base64编码：加密后得到的是二进制字节数组，无法直接在JSON等文本协议中传输。Base64编码将其转换为纯ASCII字符串，是网络传输的标配。注意使用java.util.Base64，它是JDK 8+的标准库，无需额外依赖。

4. 过滤器（Filter）的实现与请求体重写

4.1 自定义请求包装器（CustomRequestWrapper）的必要性

这是整个过滤器方案中最关键、也最容易踩坑的一环。Servlet规范规定，HttpServletRequest的输入流（getInputStream()）或读取器（getReader()）只能被读取一次。一旦读取，流就到达末尾，无法重置。

在我们的过滤器中，为了解密，我们必须先读取原始的加密请求体。如果我们直接读取了request.getInputStream()，那么后续的Controller（或者Spring MVC的参数解析器）再尝试读取时，就会抛出IllegalStateException: getReader() has already been called for this request。

解决方案就是使用装饰器模式（Decorator Pattern）。我们创建一个CustomRequestWrapper类，继承HttpServletRequestWrapper。这个包装器会：

1. 在构造时，提前读取并解密原始请求体，将解密后的明文保存在一个成员变量（如String body）中。
2. 重写getInputStream()和getReader()方法，使其返回一个基于我们保存的body重新构造的流/读取器。

这样，过滤器之后的所有组件，看到的都是一个“全新的”、可重复读取的请求，而它们读取到的内容已经是解密后的明文。

4.2 CustomRequestWrapper 实现细节

import jakarta.servlet.ReadListener; import jakarta.servlet.ServletInputStream; import jakarta.servlet.http.HttpServletRequest; import jakarta.servlet.http.HttpServletRequestWrapper; import java.io.*; public class CustomRequestWrapper extends HttpServletRequestWrapper { private final String body; public CustomRequestWrapper(HttpServletRequest request, String body) { super(request); this.body = body; // 解密后的请求体明文 } @Override public ServletInputStream getInputStream() throws IOException { final ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(body.getBytes("UTF-8")); return new ServletInputStream() { @Override public boolean isFinished() { return byteArrayInputStream.available() == 0; } @Override public boolean isReady() { return true; } @Override public void setReadListener(ReadListener readListener) { // 对于同步操作，通常不需要实现此方法 throw new UnsupportedOperationException("Not implemented"); } @Override public int read() throws IOException { return byteArrayInputStream.read(); } }; } @Override public BufferedReader getReader() throws IOException { return new BufferedReader(new InputStreamReader(this.getInputStream(), "UTF-8")); } }

注意事项：

• 编码再次强调：在将String body转换为字节数组，以及构建InputStreamReader时，务必指定UTF-8编码。
• isFinished()和isReady()方法：这两个方法是Servlet 3.0+异步处理相关的。在我们这个同步读取的场景下，isFinished()可以通过判断底层字节流是否可用来实现，isReady()直接返回true即可。setReadListener对于同步流不需要实现，可以抛出异常。
• 性能考虑：这个包装器将整个请求体保存在内存的String中。对于非常大的请求体（比如上传GB级文件），这可能会导致内存压力。在实际项目中，如果遇到超大请求体，需要评估这种方案是否合适，或者考虑分块加解密等更复杂的流式处理方案。但对于绝大多数API交互（JSON数据，通常不超过几MB），这个方案是简单有效的。

4.3 核心过滤器（SmCryptoFilter）的实现

过滤器负责串联整个流程：解密请求、包装请求、传递请求、加密响应。

import jakarta.servlet.*; import jakarta.servlet.http.HttpServletRequest; import jakarta.servlet.http.HttpServletResponse; import org.springframework.web.util.ContentCachingResponseWrapper; import java.io.BufferedReader; import java.io.IOException; public class SmCryptoFilter implements Filter { @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest = (HttpServletRequest) request; HttpServletResponse httpResponse = (HttpServletResponse) response; // 1. 解密请求体 String encryptedRequestBody = readRequestBody(httpRequest); String decryptedRequestBody; try { decryptedRequestBody = Sm4Util.decrypt(encryptedRequestBody); } catch (Exception e) { // 解密失败，可能是非法请求或密钥不对，直接返回400错误 httpResponse.setStatus(HttpServletResponse.SC_BAD_REQUEST); httpResponse.getWriter().write("Invalid encrypted request"); return; } // 2. 使用解密后的内容创建自定义请求包装器 CustomRequestWrapper requestWrapper = new CustomRequestWrapper(httpRequest, decryptedRequestBody); // 3. 包装响应，以便后续读取响应内容 ContentCachingResponseWrapper responseWrapper = new ContentCachingResponseWrapper(httpResponse); // 4. 继续执行过滤器链（包括后续的拦截器、Controller等） chain.doFilter(requestWrapper, responseWrapper); // 5. Controller执行完毕，获取明文响应体并加密 byte[] responseContent = responseWrapper.getContentAsByteArray(); if (responseContent.length > 0) { String originalResponseBody = new String(responseContent, httpResponse.getCharacterEncoding()); String encryptedResponseBody; try { encryptedResponseBody = Sm4Util.encrypt(originalResponseBody); } catch (Exception e) { throw new ServletException("Failed to encrypt response", e); } // 6. 将加密后的响应写回客户端 responseWrapper.resetBuffer(); // 清空原缓存 responseWrapper.getWriter().write(encryptedResponseBody); } // 7. 重要！必须调用此方法，将修改后的响应体真正复制到原始Response中 responseWrapper.copyBodyToResponse(); } private String readRequestBody(HttpServletRequest request) throws IOException { StringBuilder stringBuilder = new StringBuilder(); try (BufferedReader reader = request.getReader()) { String line; while ((line = reader.readLine()) != null) { stringBuilder.append(line); } } return stringBuilder.toString(); } }

关键点与优化：

1. 响应包装器（ContentCachingResponseWrapper）：为什么不用自定义的ResponseWrapper？Spring提供了ContentCachingResponseWrapper这个神器。它会把getWriter().write()写进去的内容缓存起来，之后我们可以通过getContentAsByteArray()方法拿到。这样我们就能在Filter链执行完后，拿到Controller返回的明文响应内容。注意，它只对通过getWriter()写入的内容有效，如果直接操作OutputStream，则无法捕获。

2. 异常处理：请求解密失败时（例如密文格式错误、密钥不匹配），我们直接返回400状态码并终止流程，而不是让一个错误的密文继续传递到业务层。响应加密失败则抛出异常，由Spring的全局异常处理器处理，返回500错误。生产环境可能需要更精细的错误码和日志记录。

3. copyBodyToResponse()：这是绝对不能忘记的一步！ContentCachingResponseWrapper缓存了响应，但最终需要调用这个方法，把缓存中我们修改过的内容（加密后的响应体）复制到原始的HttpServletResponse对象中，从而真正发送给客户端。如果忘了调用，客户端将收不到任何响应体。

4. 字符编码：在从responseWrapper读取字节数组并转换为字符串时，使用了httpResponse.getCharacterEncoding()。这确保了与Controller中设置的响应编码一致，避免乱码。

5. Spring Boot配置与注册

5.1 通过配置类注册过滤器

为了让Spring管理我们的过滤器并控制其拦截范围，我们通过一个@Configuration配置类来注册它。

import org.springframework.boot.web.servlet.FilterRegistrationBean; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class FilterConfig { @Bean public FilterRegistrationBean<SmCryptoFilter> smCryptoFilterRegistration() { FilterRegistrationBean<SmCryptoFilter> registrationBean = new FilterRegistrationBean<>(); registrationBean.setFilter(new SmCryptoFilter()); // 设置拦截的URL模式，通常只拦截需要加解密的API接口 registrationBean.addUrlPatterns("/api/secure/*"); // 设置过滤器名称 registrationBean.setName("smCryptoFilter"); // 设置执行顺序，数值越小优先级越高 registrationBean.setOrder(1); return registrationBean; } }

配置详解：

• addUrlPatterns：这是控制过滤器作用范围的关键。强烈建议不要使用/*拦截所有请求，这会给静态资源、健康检查端点（如/actuator/health）等带来不必要的性能开销和潜在错误。应该精确指定需要加密通信的API路径，例如/api/secure/*。
• setOrder：如果你的应用中有多个过滤器（比如还有日志过滤器、权限过滤器），这个属性决定了它们的执行顺序。加解密过滤器通常需要较早执行（Order值较小），因为后续过滤器可能需要处理解密后的明文。但也需要放在处理字符编码的过滤器（如Spring的CharacterEncodingFilter）之后。

5.2 可选：通过@Component注解自动注册

另一种更简单的方式是直接在SmCryptoFilter类上添加@Component注解，并实现Filter接口。Spring Boot会自动将其注册为一个过滤器，但此时拦截模式是/*（全部）。你可以通过@WebFilter注解来指定urlPatterns。

import jakarta.servlet.annotation.WebFilter; import org.springframework.stereotype.Component; @Component @WebFilter(urlPatterns = "/api/secure/*") public class SmCryptoFilter implements Filter { // ... 实现代码 }

这种方式更简洁，但控制力稍弱，比如无法方便地设置Order。对于简单的场景可以使用。

5.3 密钥配置化（从application.yml读取）

硬编码密钥是大忌。我们来将其改造为从配置文件读取。

application.yml:

sm4: key: ${SM4_ENCRYPTION_KEY:0123456789abcdef} # 优先从环境变量读取，默认用示例值 iv: ${SM4_ENCRYPTION_IV:fedcba9876543210}

Sm4Config.java:

import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.context.annotation.Configuration; @Configuration @ConfigurationProperties(prefix = "sm4") public class Sm4Config { private String key; private String iv; // getters and setters ... }

改造后的Sm4Util（使用Spring Bean注入）：我们不能再用静态工具类了，需要将其定义为Spring管理的Bean，以便注入配置。

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Component; import javax.annotation.PostConstruct; import java.nio.charset.StandardCharsets; import java.util.Base64; @Component public class Sm4Service { // 更名为Service更合适 @Autowired private Sm4Config sm4Config; private byte[] keyBytes; private byte[] ivBytes; @PostConstruct public void init() { // 在Bean初始化后，将配置的字符串转换为字节数组 // 这里可以增加长度校验等逻辑 if (sm4Config.getKey() == null || sm4Config.getKey().length() != 16) { throw new IllegalArgumentException("SM4 key must be 16 bytes (16 characters)"); } if (sm4Config.getIv() == null || sm4Config.getIv().length() != 16) { throw new IllegalArgumentException("SM4 IV must be 16 bytes (16 characters)"); } this.keyBytes = sm4Config.getKey().getBytes(StandardCharsets.UTF_8); this.ivBytes = sm4Config.getIv().getBytes(StandardCharsets.UTF_8); } public String encrypt(String plainText) throws Exception { // ... 使用 this.keyBytes 和 this.ivBytes ... cipher.init(true, new ParametersWithIV(new KeyParameter(this.keyBytes), this.ivBytes)); // ... } public String decrypt(String encryptedText) throws Exception { // ... 使用 this.keyBytes 和 this.ivBytes ... cipher.init(false, new ParametersWithIV(new KeyParameter(this.keyBytes), this.ivBytes)); // ... } }

然后在SmCryptoFilter中，通过@Autowired注入Sm4Service来使用加解密功能。这样，密钥的管理就安全多了，可以通过部署时的环境变量来传入真实的密钥。

6. 测试、问题排查与性能优化

6.1 编写测试Controller与接口调用

创建一个简单的测试接口，验证整个流程是否通畅。

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.*; @RestController @RequestMapping("/api/secure") public class TestController { @PostMapping("/echo") public ApiResponse<String> echo(@RequestBody UserRequest userRequest) { // 此时接收到的userRequest已经是解密后的Java对象 System.out.println("Received decrypted data: " + userRequest); // 直接返回一个对象，观察响应是否被自动加密 return ApiResponse.success("Hello, " + userRequest.getName()); } @Data // 使用Lombok public static class UserRequest { private String name; private Integer age; } @Data public static class ApiResponse<T> { private int code; private String msg; private T data; public static <T> ApiResponse<T> success(T data) { ApiResponse<T> response = new ApiResponse<>(); response.setCode(200); response.setMsg("success"); response.setData(data); return response; } } }

使用Postman或CURL进行测试：

1. 明文请求（应失败）：直接发送{"name": "张三", "age": 30}到/api/secure/echo，过滤器会尝试解密这个JSON字符串，显然会失败，应返回400错误。
2. 密文请求：
   • 先用Sm4Util.encrypt("{\"name\":\"张三\",\"age\":30}")得到密文，假设是"xyz...=="。
   • 用Postman发送POST请求到/api/secure/echo，Body选择raw->Text，内容直接粘贴密文xyz...==。
   • 查看响应，应该也是一串Base64密文。
   • 用Sm4Util.decrypt(响应密文)，应该能得到{"code":200,"msg":"success","data":"Hello, 张三"}。

6.2 常见问题排查清单

6.3 性能考量与优化建议

1. 连接复用与压缩：启用HTTPS和HTTP/2，它们本身提供传输层加密和头部压缩。对于报文体加密，如果内容较大，可以考虑在应用层先进行GZIP压缩，再进行SM4加密。虽然增加了CPU开销，但减少了网络传输量，总体可能更快。需要测试权衡。
2. 算法加速：寻找是否提供SM4硬件加速的JCE提供者（如一些国产芯片或安全软件会提供）。Bouncy Castle是纯软件实现。
3. 异步处理：如果加解密耗时确实成为瓶颈（通常在大数据量下），可以考虑将加解密操作放到异步线程池中执行，避免阻塞Netty或Tomcat的工作线程。但这会显著增加复杂性，需要谨慎评估。
4. 精准拦截：务必使用addUrlPatterns()将过滤器作用范围限制在必要的API，避免对静态资源、健康检查、内部调试接口等造成不必要的性能损耗。
5. 监控与告警：在过滤器中记录加解密的耗时，接入APM系统（如SkyWalking, Pinpoint）进行监控。设置慢请求告警，便于及时发现性能问题。

7. 生产环境进阶考量

7.1 密钥的安全管理

前文提到了从环境变量读取，这只是一个开始。生产环境的要求更高：

• 密钥分离：加解密密钥绝不能存放在代码仓库或与应用打包在一起。应该通过配置中心在应用启动时下发，或者从专用的密钥管理系统（KMS）动态获取。
• 密钥轮换：定期更换密钥是安全最佳实践。需要设计一套机制，使得新旧密钥可以在一段时间内共存，平滑过渡，不影响正在进行的请求。这通常需要在加密报文头中携带密钥版本号或密钥ID。
• 多环境隔离：开发、测试、生产环境必须使用不同的密钥。

7.2 支持多种加密算法或模式

有时，一个系统可能需要对接多个第三方，它们可能使用不同的算法（如SM4、AES）或模式（CBC、GCM）。我们的过滤器需要具备一定的扩展性。

可以定义一个加密策略接口：

public interface CryptoStrategy { String encrypt(String plainText) throws Exception; String decrypt(String encryptedText) throws Exception; String getAlgorithmIdentifier(); // 返回算法标识，如 "SM4-CBC" }

然后为SM4-CBC、AES-GCM等实现不同的CryptoStrategy。在过滤器中，可以根据请求头（如X-Encrypt-Algorithm）来动态选择使用哪种策略进行加解密。这样系统就变得更加灵活和强健。

7.3 与HTTPS的关系

这是一个常见疑问：既然用了HTTPS，为什么还要在应用层做SM4加密？

HTTPS（TLS/SSL）提供的是传输层的加密和身份认证，保障数据在客户端到服务器网络传输过程中的安全。而SM4加密是应用层加密，保障的是数据在业务系统之间或持久化存储时的安全。它们的维度不同：

• 场景一（端到端加密）：数据由客户端生成并加密，直接传给服务端。服务端存储和处理的也是密文。即使数据库泄露或服务器被入侵，攻击者拿到的也是密文。HTTPS无法提供这种保护。
• 场景二（服务间通信）：在微服务架构中，服务A调用服务B。虽然服务间通信可以用mTLS，但有时公司内网策略或架构限制，会在应用层再加一层业务定义的加密，确保即使流量被截获（比如内部人员窃听），也无法解密业务数据。

因此，HTTPS和SM4应用层加密是互补关系，而非替代关系。通常的做法是：对外暴露的API强制使用HTTPS，同时在HTTPS之上，对敏感的请求/响应体再进行一次SM4加密。

7.4 监控、日志与审计

• 脱敏日志：在过滤器中打印解密后的请求体日志时，必须对敏感信息（如手机号、身份证号、密码）进行脱敏，避免日志泄露敏感数据。
• 审计日志：记录加解密操作的成功/失败、耗时、请求来源等，便于安全审计和问题追踪。
• 熔断与降级：如果加解密服务（如调用外部KMS）出现故障，应有降级策略。例如，可以配置一个开关，紧急情况下关闭加解密过滤器，或者切换到本地缓存的旧密钥，保障核心业务可用性。

整个集成过程从设计到实现，再到生产级别的优化，需要考虑的细节远比最初想象的多。这套基于过滤器的SM4集成方案，提供了一个清晰、解耦的架构，让业务代码保持干净。在实际项目中，根据具体的性能要求、安全等级和运维能力，再对密钥管理、异常处理、监控告警等方面进行加固，就能构建出一套满足国密合规要求且稳定可靠的通信安全保障体系。