Spring Boot外部接口加密实战：混合加密与签名防篡改方案

1. 接口加密这件事，到底在防什么

先说一个真实场景：你负责的 Spring Boot 项目上线后，第三方系统要通过 HTTP 接口拉数据、推数据。你想着内网有防火墙，外网有 HTTPS 证书，数据在传输过程中是密文，应该够安全了。结果某天客户反馈，说他们的安全团队在做渗透测试时，直接用抓包工具把请求报文完整还原出来了，里面的业务字段、订单号、用户手机号全是明文。这时候你才意识到，HTTPS 解决的是“传输管道”的安全，但解决不了“看到管道里跑什么”的问题——如果调用方本身被脱库、日志被拖走、或者有人拿到了服务端的解密权限，接口数据照样裸奔。

外部访问接口的加密，核心要解决三件事：第一，接口数据在传输过程中不能被轻易还原，哪怕被截获也只是一堆无意义的乱码；第二，调用方身份必须可靠，不能随便来一个请求就能打到你的接口上；第三，请求内容不能被篡改，参数被改一个字符，服务端要能识别出来并拒绝。这三点分别对应加密、认证和完整性校验。

这篇文章不是讲理论，而是从实际项目出发，分享我在 Spring Boot 项目中给外部接口做加密的完整方案。内容包括方案选型、前端调用方改造、服务端解密实现、密钥管理、以及我踩过的坑。适合后端开发、架构师、以及对接口安全有要求的技术负责人参考。无论你的项目是 To B 的开放平台，还是内部系统对外提供数据服务，这套思路都能直接用。

先说结论：如果你的接口还在裸奔 HTTP，或者仅仅依赖 HTTPS 就认为万事大吉，那这篇文章值得你花十分钟看完。加密不是给接口“加一层壳”，而是把安全边界从传输层延伸到应用层。

2. 加密方案怎么选：先搞清楚四个问题

2.1 对称加密、非对称加密、还是混合加密

很多人的第一反应是“接口加密就用 AES”。AES 确实快，加解密性能好，但对称加密最大的问题在密钥分发：你和外部调用方共用一个密钥，这个密钥怎么安全地给到对方？邮件发一份？微信发一份？如果密钥在分发过程中泄露，加密就形同虚设。

非对称加密 RSA 解决了密钥分发问题，服务端保存私钥，公钥给调用方，调用方用公钥加密数据，服务端用私钥解密。但 RSA 加密大文本性能很差，而且本身有长度限制（1024 位密钥最多加密 117 字节，2048 位最多 245 字节），不适合直接加密整个报文。

所以我在实际项目里用的是混合加密方案：

1. 调用方每次请求前，生成一个随机的 AES 密钥（会话密钥）。
2. 用 RSA 公钥加密这个 AES 密钥，放在请求头的特定字段里。
3. 业务数据用这个 AES 密钥加密，放在请求体里。
4. 服务端先用 RSA 私钥解密出 AES 密钥，再用 AES 密钥解密业务数据。

这样既解决了密钥分发问题，又解决了 RSA 加密大数据性能差的问题。AES 密钥每次随机生成，即使某次请求被截获，也无法用同一个密钥去解密其他请求。

2.2 加密之外，还要不要做签名

加密只解决“看不懂”，不解决“是不是你发的”。如果只做加密，攻击者虽然看不懂报文内容，但可以把你的密文原封不动地重放一遍，或者把 A 请求的报文体替换到 B 请求上。这就是重放攻击和报文替换。

所以接口加密方案里必须包含数字签名。签名的作用是让服务端验证两条信息：第一，报文确实来自持有私钥的调用方（身份认证）；第二，报文内容没有被篡改（完整性校验）。

签名的方式一般有两种：先加密后签名，或者先签名后加密。我推荐先签名后加密。具体流程是：

1. 调用方把业务参数按一定规则拼接成字符串。
2. 用 RSA 私钥对这个字符串做签名（或者用 HMAC-SHA256 做摘要签名）。
3. 把明文参数 + 签名值一起加密，发送给服务端。
4. 服务端先解密得到明文和签名值，再用调用方的公钥验签。

为什么推荐先签名后加密？因为验签操作需要在服务端拿到明文后才能进行。如果先加密再签名，签名值本身是密文的签名，服务端收到后要先验签、再解密、再验签，流程多了一轮，而且密文一旦有任何字节变化，签名验证极其容易失败，排查问题时很难区分是网络传输导致的变化还是业务参数导致的差异。

2.3 国密算法要不要上

如果你的项目有等保合规要求，或者客户是金融、政务行业，大概率会被问到一个问题：能不能用国密算法？国密 SM2、SM3、SM4 对应 RSA、SHA-256、AES，性能上 SM2 弱于 RSA，但密钥长度更短，安全性理论值更高。Spring Boot 生态里用 BouncyCastle 可以支持国密算法。

但我的建议是：非强制要求的情况下，先用国际标准算法把功能跑通。原因有两个：第一，调用方如果是第三方系统，他们不一定支持国密，你的加密方案越通用，对接成本越低；第二，国密算法的调试资料相对少，出问题时排查成本高。等整体流程稳定后，再考虑把算法层抽象出来，替换成国密版本，这样不耽误主线进度。

2.4 加密要覆盖哪些内容

一个完整的接口加密方案，至少覆盖以下内容：

• 业务参数加密：请求体中的核心字段，比如手机号、身份证号、订单金额。
• 请求头敏感信息：比如调用方标识、时间戳、随机数，也应该加密或至少做签名保护。
• 响应数据加密：很多人只做请求加密，响应明文返回。这同样有问题，响应数据里可能包含敏感业务信息。我建议响应也做加密，至少对核心字段加密。
• 文件流和图片：如果接口传输的是文件流，建议整体加密或者至少做完整性校验。

我在实际项目中的做法是：对外接口统一走一套加密过滤器，不区分业务模块。这样做的好处是，新接入的接口只要加了注解就自动具备加密能力，不需要业务代码关心加解密细节。

3. 服务端实现：Spring Boot 的拦截器、过滤器、AOP 怎么选

3.1 三个方案，我为什么选了 Filter

Spring Boot 里实现请求拦截有三条路：Filter、Interceptor、AOP。它们各有适用场景：

我的选择是Filter + 自定义注解。原因是接口加解密必须在请求体被 Spring 框架转换之前完成，Filter 是最早的介入点。在 Filter 里解密完请求体后，通过包装 Request 对象，让后续的 Controller 正常读取到解密后的数据。AOP 的问题在于它是在 Controller 方法执行时才介入，而此时 request body 可能已经被 Spring 的 HttpMessageConverter 消费过了，处理起来比较绕。

3.2 Filter 里的完整处理流程

整个 Filter 的处理流程如下：

1. 从请求头获取加密类型标识、签名值、RSA 加密的 AES 密钥（会话密钥）。
2. 用服务端 RSA 私钥解密出 AES 密钥。
3. 从请求体读取密文，用 AES 密钥解密得到明文 JSON。
4. 从明文 JSON 中提取业务参数，按规则拼接后，用调用方公钥验签。
5. 验签通过后，把解密后的请求体包装成新的 request，放行给 Controller。
6. Controller 处理后，响应体在返回前经过一个 ResponseWrapper，对响应 JSON 做加密。

这个流程里最关键是第 3 步到第 5 步的顺序：先解密再验签。如果先验签，服务端就得先保存一份原始密文，但验签需要的明文此时还不存在，逻辑上说不通。所以统一采用“先解密、后验签、验签失败拒绝执行”的策略。

3.3 Request 包装器的两个坑

在 Filter 里读取请求体后重新包装 Request，是我踩坑最多的环节。有两个问题必须注意：

第一个坑：request body 只能读一次。Tomcat 底层把请求体读成流之后，InputStream 就被消费掉了，Controller 再读 body 就是空。网上很多方案是复用原来的 request，但如果没有做流重置，Controller 拿到的一定是空 body。正确做法是自定义一个CachedBodyRequestWrapper，把解密后的 body 存到字节数组里，重写getInputStream()和getReader()方法，返回字节数组的流。

第二个坑：字符编码。如果请求 Content-Type 是 application/json，默认使用 UTF-8，但有些老系统的接口会带着charset=GBK。我在解析请求体字节数组时，统一先用 Content-Type 里的 charset 解析，拿不到就用 UTF-8。如果硬编码 UTF-8，遇到 GBK 加密的数据，解密出来会乱码，而且这个乱码在验签阶段可能恰好通过，到了业务层才爆出数据库写入异常，排查半天。

3.4 响应加密的实现

响应加密我用了ResponseWrapper。思路是：在 Filter 里放行之前，把响应流替换成自定义的CachedBodyResponseWrapper，Controller 返回后，从 wrapper 中取出明文 JSON，加密后写回真正的响应流。

这里有一个细节：不是所有接口都需要响应加密。比如文件下载接口、大报表导出接口，如果对响应体整体加密，客户端得先完整接收密文再解密，内存和性能压力都会上来。我的做法是给自定义注解加一个开关属性，比如@ApiEncrypt(responseEncrypt = false)，文件流类接口主动关掉响应加密。

4. 调用方怎么配合：从拿到密钥到第一次调通

4.1 密钥分发的具体操作

在对接外部调用方时，我这边会生成两对 RSA 密钥：一对用于加密（服务端私钥解密），一对用于签名（调用方私钥签名、服务端公钥验签）。两个密钥对分开管理，避免“既当加密钥又当签名钥”的隐患。

密钥分发的实操流程：

1. 在服务端生成两对 RSA 密钥（2048 位）。
2. 调用方通过安全渠道拿到：RSA 加密公钥、验签公钥、AES 算法约定、字符集约定。
3. 调用方生成自己的签名密钥对，把签名公钥通过安全渠道发给我们。
4. 双方各自在配置中心或密钥文件里保存好对应的私钥和公钥。

关于“安全渠道”，我的经验是：不要用邮件明文传公钥。公钥虽然是公开的，但如果被中间人替换，后续的所有加密保护都会失效。建议至少做一次文件哈希校验，或者通过双方已有的安全通道、面对面的方式交换。

4.2 给调用方提供的接入文档要写什么

接入文档如果只写“请求头加 encryptKey，请求体加密”，调用方大概率会来回折腾好几轮。我的习惯是给一份可以直接使用的示例代码，包括：

• 生成 AES 随机密钥的代码。
• RSA 公钥加密 AES 密钥的代码。
• AES 加密业务 JSON 的代码。
• 签名拼接规则和签名算法代码。
• 一个完整的请求示例，包含请求头、请求体、解密响应的代码。

签名拼接规则是重点，必须定义得无歧义。我用的规则是：取业务 JSON 中的所有业务字段，按字典序排序，每个字段拼接成key=value，用&连接，最后在末尾拼上timestamp=xxx&nonce=xxx。这个字符串就是待签名字符串。

为什么强调无歧义？因为调用方如果字符串拼接顺序和你不一样，验签必然失败。最常见的问题是：数组类型字段怎么拼？嵌套对象怎么拼？我在文档里明确约定：数组直接用 JSON 数组字符串拼接，嵌套对象用 JSON 字符串拼接，不展开。这样两边实现一致，就不会因为序列化差异导致验签不通过。

4.3 时间戳防重放怎么设计

签名的另一个作用是防篡改，但要防重放攻击，还需要配合时间和随机数。我的方案是：调用方在请求头带上timestamp和nonce，服务端校验时间戳是否在 5 分钟窗口内，同时用 Redis 记录nonce，同一个 nonce 只能使用一次。

这个方案的细节在于：如果请求经过加密，timestamp和nonce是放在明文里，还是放在请求头明文？为了验签和快速校验，我将timestamp和nonce放在请求头并参与签名。服务端先校验时间窗，再查 nonce 是否重复，最后才做解密。这样可以快速拒绝大量的过期重放请求，不用白白做 RSA 解密。

Redis 中 nonce 的有效时间设成与时间窗一致，例如 5 分钟。清理工作交给 Redis 过期策略，不用额外写任务。但要注意，如果系统时钟不同步，调用方时间比你快 6 分钟，即使合法请求也会被拒。所以对接时要提醒调用方同步 NTP 时钟。

5. 密钥管理、性能调优和安全加固

5.1 密钥不能写死在代码里

我在项目初期犯过一个错误：把 RSA 私钥直接放在 application.yml 里。虽然方便，但配置中心权限管控不当的话，任何能看到配置的人都能拿到私钥。后来我改成：私钥放在独立的密钥文件中，文件权限设为仅服务账号可读，通过环境变量或配置中心注入文件路径。如果项目已经接了配置中心，推荐把私钥存到配置中心的敏感配置项中，并开启配置中心的权限控制和审计。

公钥相对没那么敏感，但也别随意暴露到客户端代码里。比较好的做法是把公钥放到调用方自己公司内部的配置系统或代码仓库的私有配置里，而不是写在前端代码或公开文档中。

5.2 性能问题：RSA 不能频繁调用

前面提到了混合加密，但服务端每次请求都要做一次 RSA 解密（把 AES 密钥解出来）。RSA 2048 私钥解密一次大约 1-3 毫秒，在单机 QPS 不高的情况下没问题，但如果是高并发接口，这个开销就会被放大。

我做过的优化有两步：第一，AES 密钥的解密结果不加缓存，因为每个请求用的 AES 密钥不同，缓存没意义；第二，把 RSA 私钥对象提前加载到内存，不要每次都从文件读取。私钥读取本身操作 I/O，如果每次请求都读文件，性能损耗比 RSA 解密本身还高。

另一个容易被忽视的点：不要在 Filter 里做耗时的日志打印。打印密文日志会带来两个问题，一是日志文件暴涨，二是序列化大字符串会拖累性能。我习惯在 Filter 里只记录请求 ID、调用方标识、时间戳、加解密耗时、解密是否成功，不记录密文和明文全文。

5.3 防止恶意请求打爆解密逻辑

加密接口还有一个风险：攻击者发送大量无效密文，服务端不断尝试用 RSA 私钥解密，解密失败后抛出异常。虽然 RSA 解密有长度限制，异常会快速返回，但仍然占用了 CPU 资源。

我在过滤器里加了三道防线：

1. 检查请求头完整性，缺少 AES 密钥头或签名头的直接返回 400，不做解密。
2. 检查密文体长度，超过预设上限的（比如 10MB）直接拒绝。
3. 限制解密失败次数，同一个调用方标识在单位时间内失败次数超过阈值，直接拉黑一段时间。

这三道防线都不涉及复杂的密码学操作，纯逻辑判断，成本很低，但能挡住很大一部分无脑扫描攻击。

5.4 日志脱敏与审计

接口加密之后，最大的变化是：传统意义上的“排查问题看日志”变得困难了。如果服务端在 Filter 解密后把明文 JSON 打到日志里，那加密就白做了。但如果完全不打日志，出问题时又没法排查。

我的做法是分两层：Filter 层只记录解密成功/失败和耗时，不记录具体内容；业务代码中通过日志切面记录操作审计时，对敏感字段做脱敏，比如手机号只保留前 3 后 2 位，身份证号只保留后 4 位。这样既保留了可追溯性，又降低了明文泄露风险。

6. 完整接入一个外部接口的实操步骤

6.1 第一步：定义注解和加密过滤器

我先定义一个注解@ApiEncrypt，用于标记需要加解密的接口：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface ApiEncrypt { boolean responseEncrypt() default true; boolean requiredSign() default true; }

Filter 中通过HttpServletRequest判断请求路径对应的方法是否带有@ApiEncrypt注解。这一步要用缓存好的接口路径与注解映射，不要在每次请求时都反射扫描所有 Controller 方法，否则性能会退化。

6.2 第二步：实现解密过滤器核心逻辑

过滤器核心逻辑的简化代码：

public class ApiDecryptFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { if (!(request instanceof HttpServletRequest)) { chain.doFilter(request, response); return; } // 检查是否需要解密 if (!shouldDecrypt(request)) { chain.doFilter(request, response); return; } // 1. 从请求头获取加密密钥密文和签名 String encryptKeyCipher = request.getHeader("Encrypt-Key"); String sign = request.getHeader("Sign"); String timestamp = request.getHeader("Timestamp"); String nonce = request.getHeader("Nonce"); // 2. 基础校验：请求头完整性 + 时间窗 if (StringUtils.isBlank(encryptKeyCipher) || StringUtils.isBlank(sign) || StringUtils.isBlank(timestamp)) { writeError(response, "missing security headers"); return; } if (!checkTimestamp(timestamp)) { writeError(response, "timestamp expired"); return; } if (!checkNonce(nonce)) { writeError(response, "nonce reused"); return; } // 3. 读取加密请求体 String bodyCipher = readBody(request); // 4. RSA 解密 AES 密钥 String aesKey; try { aesKey = rsaDecrypt(encryptKeyCipher, serverEncryptPrivateKey); } catch (Exception e) { writeError(response, "decrypt key failed"); return; } // 5. AES 解密业务数据 String bizJson; try { bizJson = aesDecrypt(bodyCipher, aesKey); } catch (Exception e) { writeError(response, "decrypt data failed"); return; } // 6. 验签 if (requiredSign && !verifySign(bizJson, timestamp, nonce, sign)) { writeError(response, "sign verify failed"); return; } // 7. 包装 request，放行 CachedBodyRequestWrapper wrapper = new CachedBodyRequestWrapper(request, bizJson.getBytes(StandardCharsets.UTF_8)); chain.doFilter(wrapper, response); } }

注意第 7 步：CachedBodyRequestWrapper必须是自定义的，否则后续@RequestBody读取不到数据。

6.3 第三步：响应加密

响应加密需要自定义一个ResponseWrapper，在 Controller 返回后，对 JSON 序列化后的字符串做 AES 加密。这个 Wrapper 的关键是重写getOutputStream()和getWriter()，把业务数据缓存到内存，等chain.doFilter返回后再统一处理。

具体流程：

CachedBodyResponseWrapper responseWrapper = new CachedBodyResponseWrapper(response); chain.doFilter(wrapper, responseWrapper); byte[] responseBody = responseWrapper.getResponseBody(); String responseJson = new String(responseBody, StandardCharsets.UTF_8); String encryptedBody = aesEncrypt(responseJson, aesKey); response.reset(); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write(encryptedBody);

这里有个容易翻车的细节：不能直接对原 response 写内容，必须在chain.doFilter返回后，等业务已经完全写完响应体，才能替换内容。如果你在 Filter 的doFilter之前就设置了响应头，后续再 reset 会把 Content-Type 等响应头清掉，所以要先 reset 再重新设置。

6.4 第四步：签名验签工具类的实现

验签工具类用 Java 原生Signature就能实现：

public class SignUtil { public static String buildSignString(Map<String, String> params) { return params.entrySet().stream() .filter(e -> e.getValue() != null && !e.getValue().isEmpty()) .sorted(Map.Entry.comparingByKey()) .map(e -> e.getKey() + "=" + e.getValue()) .collect(Collectors.joining("&")); } public static boolean verify(String publicKeyStr, String data, String sign) { try { byte[] keyBytes = Base64.getDecoder().decode(publicKeyStr); X509EncodedKeySpec keySpec = new X509EncodedKeySpec(keyBytes); KeyFactory keyFactory = KeyFactory.getInstance("RSA"); PublicKey publicKey = keyFactory.generatePublic(keySpec); Signature signature = Signature.getInstance("SHA256withRSA"); signature.initVerify(publicKey); signature.update(data.getBytes(StandardCharsets.UTF_8)); return signature.verify(Base64.getDecoder().decode(sign)); } catch (Exception e) { return false; } } }

业务参数拼接成待签名字符串时，要注意 JSON 序列化顺序不一致的问题。标准做法是：让调用方从解密后的 JSON 对象中提取字段，按字段名排序拼接。如果直接对整个 JSON 字符串做签名，两边 JSON 的 key 顺序、空格差异会导致验签失败。

6.5 第五步：客户端这边的对接实现

至少给调用方提供一份参考代码。核心片段：

// 1. 生成 AES 密钥 String aesKey = AesUtil.generateKey(); // 2. 用服务端加密公钥加密 AES 密钥 String encryptKeyCipher = RsaUtil.encrypt(aesKey, serverPublicKey); // 3. 业务数据 JSON String bizJson = objectMapper.writeValueAsString(params); // 4. 用 AES 密钥加密业务数据 String bodyCipher = AesUtil.encrypt(bizJson, aesKey); // 5. 构建待签名字符串 Map<String, String> signParams = new TreeMap<>(); signParams.putAll(params); signParams.put("timestamp", timestamp); signParams.put("nonce", nonce); String signStr = SignUtil.buildSignString(signParams); // 6. 用调用方私钥签名 String sign = RsaUtil.sign(signStr, clientPrivateKey); // 7. 发起 HTTP 请求 httpClient.post(url) .header("Encrypt-Key", encryptKeyCipher) .header("Sign", sign) .header("Timestamp", timestamp) .header("Nonce", nonce) .body(bodyCipher) .execute();

7. 加密接口联调过程的问题排查清单

7.1 问题一：验签总是失败

这是出现频率最高的问题，我总结过几个常见原因：

我在联调时最实用的一个技巧是：在服务端验签失败时，把“服务端实际参与验签的字符串”以调试日志输出，和客户端拼出的字符串做对比。这样立刻能看出差异在哪。等联调通过后，记得把调试日志关掉，防止通过日志泄露明文业务参数。

7.2 问题二：解密成功但中文乱码

乱码问题基本都是字符集不统一。客户端加密前把 JSON 转 byte 数组时必须用 UTF-8，服务端读取密文做 AES 解密时也要用 UTF-8，如果某一步用了平台默认字符集（Windows 上可能是 GBK），解密出来一定乱码。

建议在代码里统一显式指定StandardCharsets.UTF_8，不要依赖默认字符集。

7.3 问题三：请求体大于 1MB 时接口超时

外部接口传输大报文时，加密和解密的耗时都会上升。AES 加密 1MB 数据耗时在毫秒级，但 RSA 解密 AES 密钥在极端情况下可能超过 50ms，加上网络传输、业务处理、响应加密，整体延迟可能从原来的 200ms 涨到 500ms。

如果确实有大报文需求，我建议分两步优化：第一步，升级服务器性能，确保 RSA 解密操作在 CPU 密集场景下不成为瓶颈；第二步，对大报文接口单独做策略，不启用全量响应加密，只对敏感字段做加密，或者改用字段级加密（比如只加密某个字段的值）。字段级加密的缺点是暴露了字段结构，但比完全明文要好，也更容易排查问题。

7.4 问题四：加了过滤器后，所有接口都解密，导致静态资源和内部接口异常

过滤器在匹配时需要白名单机制。我通常在过滤器里维护一个shouldDecrypt逻辑：请求路径命中@ApiEncrypt注解的才处理，其余接口直接放行。注意Spring Boot Actuator的端点、静态资源、Swagger 文档等路径，必须排除在加解密范围之外。

另一个容易踩坑的是：过滤器对所有接口都生效，但调用方只对部分接口做了加密接入。如果其他内部系统没有按加密协议调用，会出现大面积报错。这时候需要在配置中心做开关控制，比如api.encrypt.enabled=true，上线初期只对指定调用方来源开启加密校验，全量切换前先把开关打开灰度跑一段时间。

7.5 问题五：怎么在加密后做接口调试

接口加密后，Swagger 直接测试变得不现实，POST 请求体已经是密文，你手动填一个 JSON 根本调不通。我的个人经验是：写一个本地的解密调试工具，或者用 Java 写一个测试客户端，封装好加解密逻辑，这样每次调试只改业务 JSON 即可。还可以在测试环境临时放开一个“内部调试端口”，走 HTTP 明文，但这个端口必须绑定在内网 IP 上，绝不能暴露到外网，否则所有加密都形同虚设。

8. 写在最后的经验补充

接口加密听上去是个独立功能，但接入后你会发现它牵扯到日志系统、监控系统、调用方排障习惯、甚至超时重试机制。我在实际项目里总结出几条内部经验，对后续维护很有帮助。

第一，加密接口的超时时间要重新评估。原来的接口 3 秒超时，加密后建议放宽到 5 秒到 8 秒。不是每次都会慢，但要在调用方侧预留合理的缓冲，否则高峰期会出现大量超时重试，重试又带来重复的 nonce，进一步触发防重放拦截，形成连锁问题。

第二，对调用方要提供一套完整的错误码说明。比如 40001 表示签名缺失，40002 表示时间戳过期，40003 表示 nonce 重复，40004 表示解密失败。调用方收到错误码就能快速定位是自身问题还是服务端配置问题，能少建很多沟通群。

第三，密钥轮换机制要提前设计。RSA 密钥不可能用一辈子，每年轮换一次是基本操作。轮换时如果调用方更新不及时，会导致解密突然大面积失败。我的做法是：在密钥中加版本号，请求头增加Key-Version字段，服务端同时维护两套密钥，旧密钥有 30 天过渡期。过渡期内新旧请求都接受，30 天后旧密钥下线。这样既保证了安全性，又给了调用方足够的迁移时间。

第四，也是我个人最深的体会：面向前端和外部系统的接口加密，本质是一次安全边界的前移，需要前后端、服务端、运维侧的协作。加密方案越早定下来越好，如果在接口已经上线几个月后再补加密，改造的沟通成本和技术成本都会成倍增加。我建议所有对外服务接口在第一个版本就把加密框架搭好，哪怕业务方暂时不启用，也要留好开关，避免后期推倒重来。