做微信机器人API接口对接的Java后端最绕不开的就是敏感数据。你从微信侧拿到的用户手机号、对话消息、身份标识甚至调用凭证任何一项在数据库里裸奔出了问题都不是小事。这套基于Spring Boot的脱敏与加密存储实战方案我已经在多个接口对接项目里稳定跑过今天主要讲清楚哪些数据需要保护、脱敏与加密怎么分工、Java代码怎么写、密钥怎么管以及微信机器人场景下几个容易踩的坑。这文章不是教科书式的原理堆砌而是直接能落到代码里的操作笔记。适合正在做微信生态接口对接的后端开发也适合准备做数据安全改造、系统里有存量敏感字段需要迁移的团队参考。看完之后你能得到一套可复用的脱敏注解、一套AES-GCM加解密工具、密钥管理的落地思路以及一套数据库灰度迁移的完整方法论。1. 先分清微信机器人接口里哪些数据算“敏感”该怎么分级1.1 四类敏感数据的边界很多人一听“敏感数据”就只想到手机号、身份证号但在微信机器人API接口场景里真正需要保护的数据远不止这些。我按来源和价值把它分成四类。第一类是用户身份与联系方式包括手机号、微信号、头像URL里的openid/unionid、邮箱、地址等。这类数据直接关联真实用户一旦泄露会引发隐私投诉也是监管重点。第二类是消息内容也就是微信侧回调给后端的历史会话、用户输入、机器人回复。消息内容里往往夹带着订单号、银行卡号、验证码甚至用户手动输入的身份证信息。这类数据如果不做分级保护日志和数据库会变成敏感信息集中营。第三类是凭证类数据包括AccessToken、refresh_token、微信回调时的Signature、EncodingAESKey以及你自己生成的登录态token。这类数据的特点是不需要被业务查询但一旦泄露等于把整个接口权限交出去了。第四类是内部调用信息比如对接第三方AI服务时的API Key、企业内部员工ID、渠道参数。这类数据不在用户隐私范围内但直接影响系统安全同样不能明文散落。这四类数据的敏感级别不一样保护手段也不一样。我一般的分级策略很简单能定位到具体用户的高价值字段手机号、身份证按最高级别加密消息内容在落库前做加密明文脱敏两份处理凭证类只允许加密存储并设置独立的访问审计内部调用信息通过配置中心或环境变量注入不落数据库。1.2 脱敏和加密的分工别混为一谈脱敏和加密是两套完全不同的逻辑但很多新手会把它们揉在一起。脱敏解决的是“不该看到时不能还原”加密解决的是“被拿走后依然不可读”。一个典型的例子用户在客服工单页面看到手机号应该是138****1234这是脱敏数据库里存的是加密后的密文这是加密存储。两者必须同时存在。从实操角度讲脱敏主要用于展示、日志、接口返回、排查问题时。加密主要用于持久化存储、缓存、消息队列投递时。要注意的是脱敏是不可逆的加密是可逆的所以不能用加密结果当脱敏结果也不能用脱敏结果当加密结果。我遇到过团队把加密字段直接返回到前端导致App端拿密文去做展示后来又临时加解密接口把密钥暴露给前端这是典型的职责混乱。正确的做法是存储层加密服务层解密后按需脱敏再返回给前端。服务端内部各模块调用时如果不需要明文就一路透传密文。2. Java后端脱敏实战用注解统一收口日志也别放过2.1 自定义脱敏注解与序列化器一个注解搞定字段脱敏脱敏最怕的是漏掉字段。人脸肉眼看一遍总有看漏的时候而且每次返回数据都要写一遍脱敏逻辑代码重复率极高。我后来采用的是“注解自定义Jackson序列化器”的方案在POJO字段上加一个注解序列化输出时自动脱敏业务代码完全不感知。首先定义脱敏类型枚举public enum SensitiveType { MOBILE, // 手机号 138****1234 ID_CARD, // 身份证号 110***********1234 NAME, // 姓名 *伟 EMAIL, // 邮箱 123****qq.com ADDRESS, // 地址 北京市海淀区**** OPENID, // openid 保留前4后4 DEFAULT // 通用 保留前1后1 }然后定义注解Retention(RetentionPolicy.RUNTIME) Target(ElementType.FIELD) public interface SensitiveMask { SensitiveType type() default SensitiveType.DEFAULT; }接下来是核心的脱敏工具类每个字段类型对应不同的正则规则public final class MaskUtil { public static String mask(String value, SensitiveType type) { if (value null || value.isEmpty()) return value; switch (type) { case MOBILE: return value.replaceAll((\\d{3})\\d{4}(\\d{4}), $1****$2); case ID_CARD: return value.replaceAll((\\d{6})\\d(\\d{4}), $1********$2); case NAME: return value.length() 1 ? * : value.substring(0, 1) *.repeat(value.length() - 1); case EMAIL: return value.replaceAll((\\w?)(\\w)(.*), $1***$3); case OPENID: return value.length() 8 ? **** : value.substring(0, 4) **** value.substring(value.length() - 4); default: return value.substring(0, 1) **** value.substring(value.length() - 1); } } }有了注解和工具类还需要让Jackson在序列化时识别它。我直接实现了一个ContextualSerializerpublic class SensitiveFieldSerializer extends JsonSerializerString implements ContextualSerializer { private SensitiveType type; public SensitiveFieldSerializer() {} public SensitiveFieldSerializer(SensitiveType type) { this.type type; } Override public void serialize(String value, JsonGenerator gen, SerializerProvider serializers) throws IOException { gen.writeString(MaskUtil.mask(value, type)); } Override public JsonSerializer? createContextual(SerializerProvider prov, BeanProperty property) { if (property null) return prov.findNullValueSerializer(property); SensitiveMask annotation property.getAnnotation(SensitiveMask.class); if (annotation ! null) { return new SensitiveFieldSerializer(annotation.type()); } return this; } }然后在字段上使用public class UserContactVO { SensitiveMask(type SensitiveType.MOBILE) private String mobile; SensitiveMask(type SensitiveType.NAME) private String userName; }这样Controller返回这个VO时Jackson会自动把mobile序列化成脱敏字符串。有个细节要注意JsonProperty的优先级比这个自定义序列化器高如果两个注解同时存在JsonProperty会覆盖序列化器可能导致脱敏失效。我踩过这个坑之后统一约定需要脱敏的字段不加JsonProperty字段命名直接与前端协议对齐。2.2 日志脱敏的坑别让log.info把手机号打出去字段返回脱敏只是第一道防线真正容易出事的是日志。一个log.info(用户下单{}, userVO)如果userVO里的mobile是明文对象那日志文件里就是明文手机号。哪怕返回前端已经脱敏日志照样泄露。这个问题比接口返回更隐蔽因为日志文件通常没有独立的访问控制还可能被同步到日志中心、告警系统泄露路径更长。我在项目里用两招解决日志脱敏。第一招自定义Logback的MessageConverter把日志输出里的手机号、身份证号直接打码。在logback-spring.xml里配置configuration conversionRule conversionWordmsg converterClasscom.demo.log.MaskLogConverter/ appender nameSTDOUT classch.qos.logback.core.ConsoleAppender encoder pattern[%d{yyyy-MM-dd HH:mm:ss}] %msg%n/pattern /encoder /appender /configuration对应的转换器public class MaskLogConverter extends MessageConverter { Override public String convert(ILoggingEvent event) { String message event.getFormattedMessage(); if (message null) return message; message message.replaceAll((\\d{3})\\d{4}(\\d{4}), $1****$2); message message.replaceAll((\\d{6})\\d(\\d{4}), $1********$2); return message; } }这个方案简单粗暴但它有个致命问题如果日志中某些场景需要看到完整手机号用于排查打码后就没法看了。所以我一般会配合第二招也就是“日志中禁止打印敏感对象”。在团队规范里规定CRUD接口的入参出参日志不准打印整个POJO而是打印脱敏后的VO或者只打印主键。代码审核阶段就直接拦掉log.info(xxx{}, user)这类写法。我个人的习惯是日志模板里用占位符时永远传脱敏后的字符串如果调试时需要完整手机号用debug级别并开启专门的敏感字段日志开关生产环境默认关闭。这比任何日志转换器都可靠因为转换器是对最终字符串做正则替换如果字段格式稍变态比如手机号中间有空格正则容易漏。3. 加密存储的选型和落地AES-GCM与SM4怎么选3.1 对称加密方案对比与选型脱敏解决展示问题加密存储才是数据保护的底线。Java后端常见的对称加密算法有AES-CBC、AES-GCM、SM4。AES-CBC是老牌方案但它需要自己处理PKCS5Padding而且密文在传输过程中容易被篡改没有完整性校验。AES-GCM是AEAD算法加密的同时生成认证标签密文一旦被改动解密时直接抛异常能防止恶意篡改这是我最推荐的一种。SM4是国密标准如果项目有等保合规或信创要求需要用到国密算法那就选SM4。它的实现方式与AES-GCM类似同样可以用GCM模式做认证加密。但从性能和生态成熟度看AES-GCM依然是绝大多数互联网项目的首选。下面我放一张我当时做选型时的对比表省得再开会争论对比项AES-CBCAES-GCMSM4完整性校验无需额外加MAC自带认证标签GCM模式自带校验性能优优同等安全级别下略快硬件支持少软实现稍慢合规场景通用通用国产化/等保Java JDK支持JDK自带JDK8自带需引入BouncyCastle推荐度不推荐推荐特定场景推荐从Java实现角度看JDK 8以上的Cipher直接支持AES/GCM/NoPadding不需要引额外的包。但要注意JCE默认的密钥长度限制如果是JDK 8需要替换local_policy.jar和US_export_policy.jar或者直接用JDK 8u161以上版本或者引入BouncyCastle。JDK 11之后默认支持256位密钥省事很多。3.2 AES-GCM加解密完整实现我直接给出一个生产可用的AES-GCM工具类里面的关键点我都标了注释。import javax.crypto.Cipher; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.nio.ByteBuffer; import java.nio.charset.StandardCharsets; import java.security.SecureRandom; import java.util.Base64; public final class AesGcmUtil { private static final int TAG_LENGTH_BIT 128; private static final int IV_LENGTH_BYTE 12; private AesGcmUtil() {} public static String encrypt(String plaintext, byte[] key) { byte[] iv new byte[IV_LENGTH_BYTE]; new SecureRandom().nextBytes(iv); try { Cipher cipher Cipher.getInstance(AES/GCM/NoPadding); SecretKeySpec keySpec new SecretKeySpec(key, AES); GCMParameterSpec gcmSpec new GCMParameterSpec(TAG_LENGTH_BIT, iv); cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmSpec); byte[] ciphertext cipher.doFinal(plaintext.getBytes(StandardCharsets.UTF_8)); ByteBuffer buffer ByteBuffer.allocate(iv.length ciphertext.length); buffer.put(iv); buffer.put(ciphertext); return Base64.getEncoder().encodeToString(buffer.array()); } catch (Exception e) { throw new IllegalStateException(AES-GCM encrypt failed, e); } } public static String decrypt(String cipherTextBase64, byte[] key) { byte[] content Base64.getDecoder().decode(cipherTextBase64); if (content.length IV_LENGTH_BYTE) { throw new IllegalArgumentException(ciphertext too short); } byte[] iv new byte[IV_LENGTH_BYTE]; System.arraycopy(content, 0, iv, 0, IV_LENGTH_BYTE); byte[] ciphertext new byte[content.length - IV_LENGTH_BYTE]; System.arraycopy(content, IV_LENGTH_BYTE, ciphertext, 0, ciphertext.length); try { Cipher cipher Cipher.getInstance(AES/GCM/NoPadding); SecretKeySpec keySpec new SecretKeySpec(key, AES); GCMParameterSpec gcmSpec new GCMParameterSpec(TAG_LENGTH_BIT, iv); cipher.init(Cipher.DECRYPT_MODE, keySpec, gcmSpec); byte[] plaintext cipher.doFinal(ciphertext); return new String(plaintext, StandardCharsets.UTF_8); } catch (Exception e) { throw new IllegalStateException(AES-GCM decrypt failed, key may be wrong, e); } } }这里有几个值得注意的细节。一是IV长度为12字节这是GCM模式的推荐长度比16字节更好用。二是加密结果把IV拼在密文前面再整体Base64这样解密时不需要额外传递IV。三是认证标签长度用128位这是当前安全性最高也最常见的配置。密钥长度我统一用256位对应32字节。如果是128位就把SecretKeySpec里的key换成16字节数组。在项目中密钥不能直接写在代码里下一节讲密钥管理。使用示例byte[] key 0123456789abcdef0123456789abcdef.getBytes(StandardCharsets.UTF_8); String ciphertext AesGcmUtil.encrypt(13812341234, key); String plaintext AesGcmUtil.decrypt(ciphertext, key);注意AES/GCM/NoPadding的doFinal内部会做Padding但GCM模式下这个Padding是认证标签不是数据补位。明文长度不要求是16的倍数这也是它比AES-CBC好用的原因之一。4. 密钥怎么管配置中心、KMS与本地密钥兜底4.1 密钥分级和信封加密思路很多初学加密的人第一反应是写死在常量类里这等于把家里钥匙挂在门把手上。正确的思路是采用密钥分级也叫信封加密。简单说业务数据用“数据密钥”加密数据密钥再用“主密钥”加密保存。主密钥由KMS或配置中心托管数据密钥可以随数据存储使用时先用主密钥解开数据密钥再用数据密钥解密业务数据。这个设计有什么好处第一主密钥可以定期更换换主密钥时不需要重新加密所有业务数据只需要用新主密钥重新加密数据密钥即可。第二数据密钥可以按业务模块隔离比如用户手机号和消息内容用不同的数据密钥一个泄露不影响另一个。第三KMS会有访问审计谁在什么时候解码了哪个密钥一目了然。我当前项目的做法是主密钥放在云厂商KMS或自建Vault里数据密钥由KMS生成后以密文形式存放在数据库的密钥表中。Java代码启动时从配置中心读取主密钥再解锁数据密钥。如果怕配置中心本身被攻破可以再加一层环境变量注入。4.2 Spring Boot里安全读取密钥的配置实践在Spring Boot项目中我没有把密钥直接写在application.yml里而是做成了环境变量和配置文件的组合。比如app: security: # 从环境变量读取不要写明文 master-key: ${MASTER_KEY} # 数据密钥的密文从配置中心或数据库获取 >Component public class CryptoKeyHolder { private volatile byte[] dataKey; public void init(Value(${app.security.master-key}) String masterKey, Value(${app.security.data-key-cipher}) String dataKeyCipher) { // 1. 用主密钥解开数据密钥密文 String dataKeyBase64 AesGcmUtil.decrypt(dataKeyCipher, masterKey.getBytes(StandardCharsets.UTF_8)); this.dataKey Base64.getDecoder().decode(dataKeyBase64); } public byte[] getDataKey() { if (dataKey null) { throw new IllegalStateException(data key not initialized); } return dataKey; } }提示主密钥是最高机密不要放进代码仓库、不要打成镜像、不要通过命令行参数直接传递。比较稳妥的方式是在部署平台的“环境变量/机密管理”里配置K8s Deployment里用secretKeyRef引用或者用Spring Cloud Config的加密配置。我还习惯在启动时做一次自检用一段已知明文测试加解密如果不通过直接fail-fast避免服务已经对外提供服务了才发现密钥不对所有查询都抛解密异常。这个自检逻辑很简单public void selfCheck() { String testPlain crypto-check; String encrypted AesGcmUtil.encrypt(testPlain, dataKey); String decrypted AesGcmUtil.decrypt(encrypted, dataKey); if (!testPlain.equals(decrypted)) { throw new IllegalStateException(crypto self check failed); } }5. 数据库字段改造与灰度迁移5.1 敏感字段加版本前缀支持新旧混存改了加密规则之后最头疼的不是写加解密代码而是数据库里已经躺着一堆明文数据。如果直接写个脚本把明文批量改成密文很容易出问题迁移过程耗时、中途失败难以回滚、服务切换时新老数据格式不一致。我的做法是在密文前面加一个算法版本前缀比如enc_v1:明文老数据不带前缀。这样服务在读数据时先判断前缀决定走解密逻辑还是直接透传。字段存储示例mobilemobile_enc_flagmobile_hash138123412340无enc_v1:eyJpdiI6...1哈希值这里的关键是读路径上做兼容比写路径更安全。因为迁移期间总会有老数据还没被改如果只按新格式读老数据就全挂了。所以读的时候public String resolveMobile(String mobile) { if (mobile ! null mobile.startsWith(enc_v1:)) { return AesGcmUtil.decrypt(mobile.substring(enc_v1:.length()), key); } return mobile; }写入的时候我干脆统一加前缀方便未来引入新算法时做多版本共存。比如未来换SM4密文前缀就是enc_sm4:旧数据还是enc_v1:两个版本都能读。5.2 老数据迁移与读写双写迁移方式我推荐定时任务分批处理而不是一次性全量update。因为大批量update会锁表而且一旦脚本里有bug恢复成本极高。我的方案分三步走服务层开启“写双写”新写入或更新的敏感字段同时更新明文老字段和密文新字段或者直接写密文让明文字段慢慢失去依赖。定时任务扫描mobile_enc_flag 0的数据每次取500条逐条重新加密并update加上limit和sleep减少对数据库的压力。每跑完一批更新flag1直到全部迁移完成最后去掉明文字段或改为空。双写期间读逻辑要复杂一些优先读密文字段如果密文字段没有值则读明文老字段并在内存中加密后回写。这样能保证数据最终一致又不影响线上响应。迁移脚本里我建议加一个“幂等标记”防止任务重复执行时重复加密。比如每次跑批之前先查询当前是否有正在处理的批次号有就直接返回。这个细节能省掉很多麻烦。5.3 加密后模糊查询的替代方案加密存储带来最大的麻烦是查询。原来where mobile ?能直接精确查现在mobile字段变成一段随机密文查询完全失效。这个问题的常规解法是加一个哈希列。把手机号等值查询的字段做哈希存到单独一列mobile_hash。哈希算法我用SHA-256拼接一个固定盐防止彩虹表。这样等值查询时只需要对入参做同样的哈希然后查索引列。这个方案不增加业务复杂度成本也低。public static String hashForQuery(String plainValue, String salt) { MessageDigest digest MessageDigest.getInstance(SHA-256); digest.update((salt plainValue).getBytes(StandardCharsets.UTF_8)); return Base64.getEncoder().encodeToString(digest.digest()); }如果业务要求模糊查询比如前后缀搜索那就比较麻烦了。哈希列解决不了模糊查询需要引入对密文做比对的开销或者牺牲一点安全性用脱敏后的值做搜索。比如手机号脱敏成138****1234存一份允许按固定格式搜索。但这样等于保留了一份半明文监管和隐私角度都比较敏感。我的态度是加密字段尽量不要做模糊查询产品设计阶段就改成“前缀掩码”搜索模式能挡住绝大多数需求。6. 微信机器人对接场景下的特殊注意点6.1 消息内容里的敏感信息识别微信机器人接口收到的用户消息最典型的就是自由文本。用户可能不按表单格式输入直接在对话里说“我的卡号是6222021234567890帮我查一下”这种情况下消息文本本身就需要先做识别再存储。光靠数据库字段加密是不够的因为整条消息如果明文存卡号就在里面。我的做法是接一层“敏感信息识别过滤器”。在消息入库前先跑一遍正则和关键词规则识别手机号、身份证号、银行卡号、邮箱等常见模式对这些片段单独加密然后把整体消息正文替换成脱敏后的文本再存储。原始明细如果需要完整保留可以加密整条消息再存一份脱敏后的副本用于运营分析。这里有个很现实的坑正则识别银行卡号容易误判普通数字串也可能命中。所以我不会只靠正则还叠加了Luhn算法校验银行卡号短信验证码这种6位数字也容易被误伤我一般只提取5位以上连续数字做上下文关键词判断。实际的准确率不可能100%但能覆盖90%以上常见敏感数据。6.2 Token与AccessToken的存储规范微信机器人API对接一定绕不开AccessToken的获取与刷新。很多人的做法是直接缓存在Redis里key结构类似wx:access_token:appidvalue就是明文的token。这等于把登录凭证放在了相对开放的缓存环境里一旦Redis被扫描到未授权访问攻击者可以拿着token冒充机器人身份。我的存法分两类如果是需要频繁读取并且不希望每次都解密的token可以用Redis缓存但value存加密后的token读取时解密如果token本身很少读取那就直接存数据库密文用的时候再解密。无论是哪种我都不会把token写到日志的queryString里也不打AccessToken的明文日志。另外微信回调里的Signature和TimeStamp校验要放在接入层不要等到业务层再做。对于EncodingAESKey这种加解密密钥建议放在专属配置项里和普通业务配置隔离开最好独立一个加密配置中心防止和其他配置一起泄露。6.3 回调数据验签、解密与脱敏的完整链路微信机器人的回调接口数据链路一般是微信服务器 - 你的接口 - 消息队列 - 业务处理 - 落库。每一步都可能留下敏感数据。比如接口层如果直接打印原始请求body回调里携带的消息原文就进了日志如果业务处理抛异常时异常信息带了明文消息也会泄露。我设计的链路分四步接入层先验签验签通过后才解析body。验签失败直接返回错误不打印明文body。在解析后的第一个环节立刻对消息内容做敏感信息识别与脱敏生成一份“脱敏消息”和一份“加密消息”。脱敏消息用于日志、监控、人工客服查看加密消息用于落库、后续业务处理。业务处理内部如果需要完整原文只在内存中解密使用使用完立即丢弃引用不缓存、不打印。这套链路下来明文生命周期被压缩到最小。哪怕数据库被拖走攻击者拿到的也是一批密文哪怕日志被拉走看到的也是脱敏后的文本。7. 常见问题与排查技巧实录7.1 加密字段变长、乱码与Base64AES-GCM加密后是二进制密文必须用Base64编码才能放进VARCHAR字段和JSON。很多新手直接new String(byte[])去存结果存进去是乱码取出来解密直接失败。这个问题的根源是二进制到字符串的转换方式不对正确的方式只有Base64或Hex。另外字段长度一定要预留足够。手机号明文是11个字符加密后Base64字符串通常是36个字符左右如果数据库字段是VARCHAR(20)插入就会报错。更要命的是GCM的认证标签本身也占了密文长度如果用工具类把IV拼在密文前面整体长度会进一步增加。我的建议是敏感字段类型直接上VARCHAR(256)哪怕对手机号这种短字段也留够余量避免未来换算法时长度不够用。7.2 嵌套对象不触发脱敏注解我遇到过的情况是自定义序列化器对外层字段生效但对List 里的UserContactVO不生效。排查后发现问题出在Jackson的ContextualSerializer实现里我没有处理BeanProperty为null的情况。这个坑的规律是如果字段本身是集合类型Jackson会先创建集合序列化器再对集合内泛型字段调用createContextual。此时property仍然存在但如果我返回了this序列化器没有初始化type结果直接走默认脱敏把名字也打码了。解决办法是在createContextual中对每个字段重新创建新的SensitiveFieldSerializer而不是复用同一个实例并且在没有注解时返回prov.findNullValueSerializer(property)。7.3 密钥轮换后老数据解密失败轮换密钥是安全要求但轮换不当会让老数据全部解密失败。问题出在我直接用新密钥解密所有旧数据没有考虑旧数据是用旧密钥加密的。解决这个问题的标准做法是支持多密钥版本。具体实现是在密文前缀里带上密钥版本比如enc_v1:keyId:base64data解密时解析出keyId从密钥表里找到对应的旧密钥。这样轮换时新数据用新密钥加密老数据继续用旧密钥解同时给老数据设置一个过期迁移时间在迁移窗口内逐步用新密钥重新加密。我在系统里实时监控解密失败率一旦出现莫名上升最先查的就是密钥版本是否匹配。日志里一定要打keyId不要只打algorithm否则排查时还得靠猜。下面整理一个速查表方便直接对照处理现象原因处理办法数据库出现中文乱码二进制直接new String统一用Base64编码存储插入密文报字段超长字段长度不够改成VARCHAR(256)解密抛AEADBadTagException密钥不匹配或密文被篡改检查keyId、更换密钥后重新加密日志脱敏正则失效格式不规范存在空格/分隔符先归一化再脱敏或字段级脱敏返给前端仍是明文序列化器未生效检查是否有JsonProperty覆盖加密后无法查询密文随机性导致等值失效增加哈希索引列Token泄露Redis缓存未加密改为密文缓存或加密存储消息内容敏感识别误判正则太宽泛叠加上下文关键词与校验算法做微信机器人API接口的数据安全改造我最大的感触是“加密不是终点解密后的管控才是重点”。很多系统引入了AES-GCM但解密后的明文在日志、缓存、排查工具里又转了一圈等于白干。所以我现在的习惯是每一次解密操作都要有明确的原因能不还原明文就不还原能短时间持有明文就绝不长时间缓存。如果你刚接手一个老项目不要急着把所有字段一次性全量加密。先把新入库的数据切到加密存储再慢慢迁移老数据同时把日志脱敏和展示脱敏做起来。这套组合拳打下来敏感数据的防护等级会有质的提升而且每一步都是可回滚、可灰度验证的不会因为一次改造把自己和同事搞得彻夜不眠。