1. 项目概述与核心痛点最近在做一个SpringBoot项目数据库连接信息用户名、密码直接写在application.yml里心里总觉得不踏实。虽然项目部署在内网但配置文件跟着代码一起提交到Git仓库万一哪天仓库权限没管好或者服务器被拖库数据库就直接“裸奔”了。这可不是危言耸听安全无小事尤其是涉及核心数据的连接凭证。市面上常见的方案是使用Jasypt这类成熟的加密库它确实不错开箱即用。但我在实际项目中特别是对接一些有特定安全审计要求的场景时有时需要更清晰地掌控加密解密的整个流程或者希望加密逻辑能更紧密地与MybatisPlus这类持久层框架结合。比如我们可能希望加密不仅仅是启动时解密一次而是在MybatisPlus建立每一个数据库连接时动态地对配置项进行解密。这给了我一个启发能不能用MybatisPlus的扩展点结合最常用的对称加密算法AES自己实现一套对yml中数据库连接信息的加密解密机制呢这个方案的核心价值在于将安全控制下沉到应用层实现配置信息的“运行时解密”。配置文件里存储的是密文即使泄露也无法直接使用。而解密密钥AES的密钥则通过更安全的方式如环境变量、启动参数、密钥管理服务传入实现了配置与密钥的分离。这样一来代码仓库里的配置文件就不再是安全短板了。接下来我就把这次从思路到落地的完整过程以及踩过的坑和优化心得详细分享一下。2. 技术方案选型与设计思路拆解2.1 为什么选择AES而非其他算法首先得说说为什么选AESAdvanced Encryption Standard。面对数据库密码这种需要加解密的场景对称加密算法是首选因为它的加解密速度快适合对大量数据或频繁操作的数据进行加密。在对称加密算法家族里DES已经因为密钥过短被淘汰3DES效率偏低而AES是当前国际公认的安全且高效的对称加密标准。AES有几个关键参数密钥长度128, 192, 256位、工作模式如ECB, CBC, GCM等、填充模式如PKCS5Padding。对于配置文件加密我推荐使用AES/CBC/PKCS5Padding。为什么不选ECB因为ECB模式加密相同的明文块会产生相同的密文块安全性较弱容易被分析。CBC模式引入了初始化向量IV使得即使明文相同加密后的密文也不同安全性更高。PKCS5Padding则是Java平台最常用的填充方式。密钥长度我选择了256位它提供了更高的安全性虽然某些早期JDK版本可能需要安装“Java加密扩展无限制强度管辖权策略文件”但现在主流的JDK 8及以上版本通常都支持。2.2 MybatisPlus如何介入配置加载过程Spring Boot应用启动时会从application.yml中读取spring.datasource下的配置如url,username,password并据此构造DataSource对象。MybatisPlus本身并不直接管理这个流程它是在DataSource之上进行封装的。因此我们干预的时机不是在MybatisPlus内部而是在Spring Boot创建DataSource之前。我们的目标是在配置属性被注入到DataSource属性之前拦截这些属性值如果是密文我们可以定义一个前缀如ENC(则对其进行AES解密然后将解密后的明文交给后续流程。这听起来像是PropertySource或BeanFactoryPostProcessor该干的事。但有一个更优雅、与MybatisPlus生态结合更紧密的方式自定义一个DataSourceBean。我们可以自己定义一个DataSource在构造它的时候对从环境Environment中获取到的原始配置值进行解密判断和处理。这样加解密逻辑就封装在了数据源初始化环节对上层MybatisPlus完全透明它感知不到解密过程就像在使用普通的配置一样。2.3 整体架构设计整个方案的流程图在脑海里是这样的应用启动加载application.yml。我们自定义的DataSource配置类比如叫EncryptedDataSourceConfig被加载。在这个配置类中我们通过Value或Environment对象获取到spring.datasource.password等属性的值。判断获取到的值是否是我们定义的密文格式例如以ENC(开头以)结尾。如果是密文则调用我们编写的AES解密工具类使用预先配置好的密钥从系统环境变量DB_ENCRYPT_KEY中获取进行解密。将解密后的明文作为参数用于构造真正的DataSourceBean如HikariCP。MybatisPlus自动配置会使用我们这个自定义的DataSourceBean从而建立数据库连接。这样设计的好处是职责清晰AES工具负责算法配置类负责识别和解密密钥由外部环境提供。接下来我们进入具体的实现环节。3. 核心工具类AES加解密实现详解工欲善其事必先利其器。我们先来实现最核心的AES加解密工具类。这里会包含很多细节和坑我会一一说明。3.1 AES工具类的完整实现创建一个AesUtil类。这里采用CBC模式因为它更安全。CBC模式需要一个初始化向量IV为了简单起见我们可以将IV和密钥关联起来例如使用密钥的前16字节作为IV但在生产环境中IV最好是随机生成并和密文一起存储。为了简化示例我们采用一种固定IV的方式但你要知道这不是最安全的方式后续我会讲优化方案。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 TRANSFORMATION AES/CBC/PKCS5Padding; /** * 算法名称 */ private static final String ALGORITHM AES; /** * 字符编码 */ private static final String CHARSET UTF-8; /** * 加密 * param content 明文 * param key 密钥必须为16、24或32字节对应AES-128/192/256 * return Base64编码的密文 */ public static String encrypt(String content, String key) throws Exception { // 参数校验 if (content null || key null) { throw new IllegalArgumentException(Content and key must not be null); } // 检查密钥长度 byte[] keyBytes key.getBytes(StandardCharsets.UTF_8); if (!isKeyLengthValid(keyBytes.length)) { throw new IllegalArgumentException(Invalid AES key length: keyBytes.length bytes. Must be 16, 24, or 32 bytes.); } // 1. 生成密钥规范 SecretKeySpec secretKeySpec new SecretKeySpec(keyBytes, ALGORITHM); // 2. 使用密钥的前16字节作为固定IV仅示例生产环境建议随机IV byte[] ivBytes new byte[16]; System.arraycopy(keyBytes, 0, ivBytes, 0, Math.min(keyBytes.length, 16)); IvParameterSpec ivParameterSpec new IvParameterSpec(ivBytes); // 3. 初始化Cipher为加密模式 Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivParameterSpec); // 4. 执行加密 byte[] encryptedBytes cipher.doFinal(content.getBytes(CHARSET)); // 5. 返回Base64编码的字符串 return Base64.getEncoder().encodeToString(encryptedBytes); } /** * 解密 * param encryptedContent Base64编码的密文 * param key 密钥必须与加密时一致 * return 明文 */ public static String decrypt(String encryptedContent, String key) throws Exception { // 参数校验 if (encryptedContent null || key null) { throw new IllegalArgumentException(Encrypted content and key must not be null); } byte[] keyBytes key.getBytes(StandardCharsets.UTF_8); if (!isKeyLengthValid(keyBytes.length)) { throw new IllegalArgumentException(Invalid AES key length: keyBytes.length bytes.); } // 1. 生成密钥规范 SecretKeySpec secretKeySpec new SecretKeySpec(keyBytes, ALGORITHM); // 2. 使用与加密相同的IV byte[] ivBytes new byte[16]; System.arraycopy(keyBytes, 0, ivBytes, 0, Math.min(keyBytes.length, 16)); IvParameterSpec ivParameterSpec new IvParameterSpec(ivBytes); // 3. 初始化Cipher为解密模式 Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivParameterSpec); // 4. Base64解码并执行解密 byte[] encryptedBytes Base64.getDecoder().decode(encryptedContent); byte[] decryptedBytes cipher.doFinal(encryptedBytes); // 5. 返回明文字符串 return new String(decryptedBytes, CHARSET); } /** * 校验密钥长度是否合法 */ private static boolean isKeyLengthValid(int length) { return length 16 || length 24 || length 32; } }注意上面的工具类使用了固定的IV生成方式取密钥的前16字节。这只是一个示例。在真正的生产环境中CBC模式要求每次加密使用一个随机、不可预测的IV并且需要将IV和密文一起存储。通常的做法是加密时生成随机IV将IV和密文拼接如IV 密文然后整体做Base64编码。解密时先Base64解码分离出IV和密文再用这个IV进行解密。这样可以确保相同明文每次加密结果都不同安全性更高。你可以根据这个思路去优化encrypt和decrypt方法。3.2 密钥管理安全的重中之重密钥绝对不能硬编码在代码中这是铁律。常见的做法有系统环境变量在服务器上设置环境变量如DB_ENCRYPT_KEY。在Java代码中通过System.getenv(DB_ENCRYPT_KEY)获取。这是最简单也相对安全的方式。启动参数在启动Jar包时通过-D参数传入如java -jar app.jar -Ddb.encrypt.keyyour_key_here。代码中通过System.getProperty(db.encrypt.key)获取。密钥管理服务KMS在云环境或大型系统中使用如阿里云KMS、AWS KMS、HashiCorp Vault等专业服务来管理密钥应用在启动时动态获取。这是最安全的方式但架构复杂。在我们的示例中将采用环境变量的方式。你需要确保你的部署环境如Linux服务器中已经正确设置了该环境变量。3.3 密文格式定义与识别为了能明确区分配置项是明文还是密文我们需要定义一个格式。常见的格式是模仿Jasypt用括号包裹例如ENC(密文内容)。我们的工具类可以增加一个判断和剥离格式的方法public class ConfigEncryptionUtil { private static final String ENCRYPTED_PREFIX ENC(; private static final String ENCRYPTED_SUFFIX ); /** * 判断一个配置值是否是加密格式 */ public static boolean isEncryptedValue(String value) { return value ! null value.startsWith(ENCRYPTED_PREFIX) value.endsWith(ENCRYPTED_SUFFIX); } /** * 从加密格式中提取出密文内容 */ public static String extractEncryptedContent(String encryptedValue) { if (!isEncryptedValue(encryptedValue)) { return encryptedValue; // 如果不是加密格式原样返回可能是明文 } // 剥离 ENC(...) 外壳 return encryptedValue.substring(ENCRYPTED_PREFIX.length(), encryptedValue.length() - ENCRYPTED_SUFFIX.length()); } /** * 将密文内容包装成加密格式 */ public static String wrapEncryptedContent(String encryptedContent) { return ENCRYPTED_PREFIX encryptedContent ENCRYPTED_SUFFIX; } }这样在配置文件中加密的密码就可以写成password: ENC(AK9L8sS7v...xxx...)而明文的配置则保持不变。4. 整合Spring Boot自定义加密数据源配置这是将加解密能力注入Spring容器的关键一步。我们将创建一个配置类来提供自定义的DataSourceBean。4.1 创建数据源配置类import com.zaxxer.hikari.HikariDataSource; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.context.annotation.Primary; import org.springframework.core.env.Environment; import javax.sql.DataSource; Configuration public class EncryptedDataSourceConfig { Autowired private Environment env; /** * 从环境变量获取AES密钥 */ private String getEncryptionKey() { String key System.getenv(DB_ENCRYPT_KEY); if (key null || key.trim().isEmpty()) { // 可以尝试从系统属性获取或者抛出明确的异常 key System.getProperty(db.encrypt.key); if (key null) { throw new IllegalStateException(数据库加密密钥未配置请设置环境变量 DB_ENCRYPT_KEY 或系统属性 db.encrypt.key); } } return key.trim(); } /** * 处理配置值如果是加密格式则解密否则原样返回。 */ private String processValue(String rawValue) { if (ConfigEncryptionUtil.isEncryptedValue(rawValue)) { try { String encryptedContent ConfigEncryptionUtil.extractEncryptedContent(rawValue); String key getEncryptionKey(); return AesUtil.decrypt(encryptedContent, key); } catch (Exception e) { throw new RuntimeException(解密数据库配置失败请检查密钥和密文格式是否正确。原始值: rawValue, e); } } // 非加密格式直接返回 return rawValue; } Primary // 如果有多个DataSource这个优先 Bean(name dataSource) public DataSource dataSource() { // 1. 从Environment中获取原始配置值 String url env.getProperty(spring.datasource.url); String username env.getProperty(spring.datasource.username); String password env.getProperty(spring.datasource.password); String driverClassName env.getProperty(spring.datasource.driver-class-name, com.mysql.cj.jdbc.Driver); // 2. 对可能加密的值进行处理 String processedUrl processValue(url); String processedUsername processValue(username); String processedPassword processValue(password); // 3. 使用处理后的值构建HikariCP数据源推荐 HikariDataSource dataSource new HikariDataSource(); dataSource.setJdbcUrl(processedUrl); dataSource.setUsername(processedUsername); dataSource.setPassword(processedPassword); dataSource.setDriverClassName(driverClassName); // 4. 可以继续设置其他连接池参数如最大连接数、超时时间等 // dataSource.setMaximumPoolSize(20); // dataSource.setConnectionTimeout(30000); // ... return dataSource; } }这个配置类做了几件关键事情密钥获取优先从环境变量DB_ENCRYPT_KEY读取密钥备选从系统属性读取。如果都为空则直接抛出异常防止密钥缺失导致明文存储或连接失败。配置处理定义了processValue方法它利用前面写的ConfigEncryptionUtil和AesUtil对每一个配置值进行判断和解密。构建数据源使用处理后的即解密后的明文URL、用户名、密码来构造HikariCP数据源。这里我用了HikariDataSource它是Spring Boot 2.x的默认连接池性能很好。你也可以用DruidDataSource等其他实现。4.2 调整application.yml配置文件现在你的application.yml可以这样写了spring: datasource: url: jdbc:mysql://localhost:3306/my_encrypted_db?useSSLfalseserverTimezoneUTC username: ENC(你的加密后的用户名密文) # 例如ENC(U2FsdGVkX1...) password: ENC(你的加密后的密码密文) # 例如ENC(qX8wS7dF...) driver-class-name: com.mysql.cj.jdbc.Driver # 注意这里不再需要配置 hikari 或 type因为我们在配置类里手动创建了DataSource Bean # 其他配置...重要由于我们通过Bean手动创建了DataSourceSpring Boot的自动配置DataSourceAutoConfiguration可能会因为检测到已有DataSource Bean而跳过也可能因为某些属性不匹配而产生冲突。为了更稳妥你可以在application.yml中不再设置spring.datasource.hikari.*这类连接池具体属性而是像上面一样只提供最基础的url、username等。连接池的高级配置如maximumPoolSize可以在EncryptedDataSourceConfig类的dataSource()方法中通过dataSource.setMaximumPoolSize(20)这样的方式硬编码或者通过ConfigurationProperties绑定到一个配置类上再注入进来后者更灵活。5. 完整实操流程与测试验证理论说完了我们从头到尾操作一遍确保你能成功跑起来。5.1 第一步生成加密密文在把密文写到配置文件之前你得先有密文。写一个简单的主类或者单元测试来生成它。import java.util.Scanner; public class EncryptGenerator { public static void main(String[] args) throws Exception { Scanner scanner new Scanner(System.in); System.out.print(请输入需要加密的明文 (如数据库密码): ); String plainText scanner.nextLine(); System.out.print(请输入AES密钥 (16/24/32字节): ); String key scanner.nextLine(); // 检查密钥长度 if (key.getBytes(UTF-8).length % 8 ! 0 || key.getBytes(UTF-8).length 32) { System.err.println(密钥长度不符合要求请确保是16、24或32字节英文/数字通常一个字符一字节。); return; } String cipherText AesUtil.encrypt(plainText, key); String wrappedCipherText ConfigEncryptionUtil.wrapEncryptedContent(cipherText); System.out.println(\n--- 加密结果 ---); System.out.println(原始明文: plainText); System.out.println(加密密钥: key); System.out.println(生成的密文: cipherText); System.out.println(供配置文件使用的格式: wrappedCipherText); System.out.println(----------------); // 可选验证解密 String decryptedText AesUtil.decrypt(cipherText, key); System.out.println(解密验证结果: (plainText.equals(decryptedText) ? 成功 : 失败)); } }运行这个程序输入你的数据库密码和密钥比如一个32位的字符串my-32byte-ultra-secure-key-123456你会得到类似ENC(U2FsdGVkX19zZWNyZXR...)的字符串。把这个字符串复制到application.yml的password后面。5.2 第二步设置环境变量并启动在启动你的SpringBoot应用之前必须让应用能拿到密钥。Linux/Mac在终端执行export DB_ENCRYPT_KEYmy-32byte-ultra-secure-key-123456然后再java -jar your-app.jar。Windows (CMD)执行set DB_ENCRYPT_KEYmy-32byte-ultra-secure-key-123456然后再java -jar your-app.jar。IDE中运行 (如IntelliJ IDEA)在运行配置Run/Debug Configuration的“Environment variables”栏添加DB_ENCRYPT_KEYmy-32byte-ultra-secure-key-123456。Docker在docker run命令中添加-e DB_ENCRYPT_KEYmy-32byte-ultra-secure-key-123456。5.3 第三步验证与测试启动应用观察日志。如果一切正常应用会成功启动并连接到数据库。你可以在EncryptedDataSourceConfig的processValue方法里加一些日志打印出处理前后的值方便调试。private String processValue(String rawValue) { System.out.println([Config Decrypt] Processing raw value: (rawValue ! null ? *** : null)); // 避免日志打印完整密码 if (ConfigEncryptionUtil.isEncryptedValue(rawValue)) { try { String encryptedContent ConfigEncryptionUtil.extractEncryptedContent(rawValue); String key getEncryptionKey(); String decrypted AesUtil.decrypt(encryptedContent, key); System.out.println([Config Decrypt] Value decrypted successfully.); return decrypted; } catch (Exception e) { throw new RuntimeException(解密数据库配置失败, e); } } System.out.println([Config Decrypt] Value is plain text, using as is.); return rawValue; }更正式的测试是写一个简单的集成测试使用SpringBootTest确保DataSourceBean能被正确创建并且能执行一条简单的SQL查询如SELECT 1这能证明解密和连接都成功了。6. 生产级优化与深度避坑指南把基础功能跑通只是第一步要上生产环境还有很多细节需要打磨和避坑。6.1 安全性强化IV处理与算法模式问题前面工具类使用了固定的IV存在安全风险。优化实现随机IV并将IV与密文一起存储。修改AesUtilpublic class AesUtilPro { private static final String TRANSFORMATION AES/CBC/PKCS5Padding; private static final String ALGORITHM AES; private static final int IV_LENGTH 16; // AES块大小是16字节 private static final String CHARSET UTF-8; /** * 加密输出格式为 Base64(IV 密文) */ public static String encrypt(String content, String key) throws Exception { // ... 密钥校验同上 ... SecretKeySpec secretKeySpec new SecretKeySpec(key.getBytes(CHARSET), ALGORITHM); // **生成随机IV** byte[] iv new byte[IV_LENGTH]; SecureRandom secureRandom new SecureRandom(); secureRandom.nextBytes(iv); IvParameterSpec ivSpec new IvParameterSpec(iv); Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, secretKeySpec, ivSpec); byte[] encrypted cipher.doFinal(content.getBytes(CHARSET)); // 合并IV和密文 byte[] combined new byte[iv.length encrypted.length]; System.arraycopy(iv, 0, combined, 0, iv.length); System.arraycopy(encrypted, 0, combined, iv.length, encrypted.length); return Base64.getEncoder().encodeToString(combined); } /** * 解密输入格式为 Base64(IV 密文) */ public static String decrypt(String combinedEncrypted, String key) throws Exception { // ... 密钥校验同上 ... byte[] combined Base64.getDecoder().decode(combinedEncrypted); // 分离IV和密文 byte[] iv new byte[IV_LENGTH]; byte[] encrypted new byte[combined.length - IV_LENGTH]; System.arraycopy(combined, 0, iv, 0, IV_LENGTH); System.arraycopy(combined, IV_LENGTH, encrypted, 0, encrypted.length); SecretKeySpec secretKeySpec new SecretKeySpec(key.getBytes(CHARSET), ALGORITHM); IvParameterSpec ivSpec new IvParameterSpec(iv); Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, secretKeySpec, ivSpec); byte[] decrypted cipher.doFinal(encrypted); return new String(decrypted, CHARSET); } }同时ConfigEncryptionUtil中wrapEncryptedContent和extractEncryptedContent方法处理的已经是新的Base64(IV密文)格式的整体字符串了。更进一步考虑使用更安全的认证加密模式如AES/GCM/NoPadding。GCM模式同时提供了加密和完整性认证比CBC更安全且不需要单独的填充。Java 8及以上版本支持。使用GCM时需要注意处理认证标签Authentication Tag。6.2 密钥管理与轮转策略问题密钥写死在环境变量里如何轮转策略密钥版本化在密文格式中嵌入密钥版本号如ENC(v1密文)。应用启动时根据版本号从安全的存储如环境变量DB_KEY_v1,DB_KEY_v2中读取对应的密钥。这样在轮转时新旧密钥可以并存一段时间。动态获取在getEncryptionKey()方法中集成调用KMS或Vault的客户端API动态获取当前活跃的密钥。这需要网络调用可以考虑增加本地缓存并处理好KMS不可用时的降级策略但降级策略本身需要极其谨慎避免回退到不安全状态。6.3 与MybatisPlus及其他配置的兼容性问题一MybatisPlus的配置如分页插件、性能分析拦截器通常也需要DataSource我们的自定义DataSourceBean是否能被正确注入答案只要我们的Bean方法返回的是DataSource类型并且被Primary标注或者在MP配置中通过Qualifier指定Bean名称MybatisPlus的自动配置就能正确使用它。确保你的MybatisPlus配置类如果有里注入的DataSource没有歧义即可。问题二除了数据库密码其他敏感配置如Redis密码、第三方API Secret也想加密怎么办扩展我们的processValue逻辑可以抽象成一个通用的PropertySource或BeanPostProcessor。更优雅的方式是自定义一个EnvironmentPostProcessor在Spring Boot环境准备阶段遍历所有属性对符合特定格式如{cipher}...的值进行解密并替换回环境里。这样任何通过Value或Environment获取的属性都会自动解密适用范围更广。不过实现复杂度会高一些。6.4 性能与异常处理考量性能加解密操作只在应用启动时、构造DataSourceBean时执行一次对运行时性能几乎没有影响。异常处理在processValue方法中解密失败一定要抛出明确的运行时异常如IllegalStateException并附带清晰的错误信息让运维人员能快速定位是密钥错误、密文损坏还是格式不对。避免默默失败导致使用错误密码去连接数据库。6.5 一个真实的踩坑记录JDK版本与密钥长度我曾经在JDK 8u161版本上遇到一个错误java.security.InvalidKeyException: Invalid AES key length: 14 bytes。明明我的密钥是32字节为什么报14字节排查后发现是因为密钥字符串中包含了中文字符或特殊字符在不同环境下获取时如从Windows的批处理文件设置环境变量编码可能出问题导致getBytes()后的字节数组长度不符合预期。解决方案强制使用key.getBytes(StandardCharsets.UTF_8)来确保编码一致。在密钥生成和传递环节尽量使用纯ASCII字符字母、数字、常见符号避免中文和复杂特殊字符。在工具类的getEncryptionKey()方法中加入严格的长度校验和日志打印打印长度不打印内容便于调试。7. 总结与延伸思考通过以上步骤我们实现了一个与MybatisPlus无缝集成、基于AES的数据库连接信息加密方案。它核心在于利用Spring的Bean生命周期在数据源初始化这个关键节点插入解密逻辑。这个方案的好处是清晰、可控并且与具体的ORM框架MybatisPlus解耦。回顾整个过程最重要的几点心得是安全是一个链条加密配置文件只是其中一环。密钥的安全存储环境变量、KMS、传输、轮转同样重要甚至更重要。理解底层原理不要满足于调用一个encrypt方法。理解AES的不同模式、IV的作用、填充的机制能让你在遇到诡异问题时更快地定位比如为什么同样的密钥在Java和Python下加密结果不同可能是模式或填充不同。适配与兼容在Spring Boot的自动配置海洋里自定义Bean要小心处理好与原有配置的关系。多测试在不同配置组合下的启动情况。日志与监控加解密环节要有适当的日志输出注意不要日志敏感信息本身方便在部署和运维阶段排查问题。这个方案还可以进一步扩展比如支持多种加密算法SM4等国密算法、集成Spring Cloud Config Server实现配置中心加密等。但核心思想不变将秘密密码与配置密文分离让每个环节各司其职共同构筑起应用配置的安全防线。