1. 一段险些泄露数据库密码的经历Jasypt解决什么问题不解决什么问题先讲个让我下定决心用Jasypt的真实场景。之前有个项目团队为了方便本地联调直接把生产环境MySQL密码写在了application.yml里还顺手提交到了私有Git仓库。结果没过多久一位同事在公共平台搜索代码片段的时候发现我们项目的配置片段已经被某些爬虫索引了数据库密码、Redis密码、第三方AppSecret一眼全露。虽然那只是一个内部测试库但当场改密码、清理提交历史、还要排查有没有被外部访问过的流程真的让人后背发凉。如果你也遇到过类似情况或者说你正接手一个配置里全是明文密钥的项目那Jasypt值得你花半小时了解一下。Jasypt的全称是Java Simplified Encryption一个老牌的Java加解密库。它做两件事一是基于口令的加密PBEPassword Based Encryption二是一些摘要、散列相关的能力。在Spring Boot项目里最常见的用法就是把配置文件中的敏感值——数据库密码、Redis密码、令牌、接口密钥——从明文替换成密文再用ENC(密文)这种格式写进配置文件。应用启动时Jasypt会自动把对应属性的密文解密成明文交给Spring容器使用业务代码几乎不需要感知它的存在。它解决的核心痛点是配置文件本身可能被提交、被分享、被备份、被索引的常态化风险。你没法保证每个拿到代码的人都会小心保管也没法保证代码托管平台不出意外所以最稳妥的做法就是让配置文件即使被翻源码也拿不到真实密钥。但我得先把丑话说在前面Jasypt不是银弹。它属于“低成本、中等强度”的配置保护方案加密用的口令password最终还是要存在某个地方通常是环境变量或者启动参数。如果你的服务器环境本身就不可信或者你需要在分布式场景下频繁轮换密钥、做审计、做权限隔离那应该去考虑Vault、KMS这类专业密钥管理方案。但对于大多数中小团队Jasypt是性价比最高、改造代价最小的一条路。这篇文章会带你完整过一遍底层原理、依赖选型、生成密文的几种方式、在Spring Boot项目里从零接入的步骤、我实际踩过的坑以及密钥管理和多环境设计的一些建议。全程可复现不需要你懂密码学只需要按步骤操作。2. Jasypt底层原理拆解口令、盐和迭代次数是怎么回事很多人用Jasypt只会配不理解它内部是怎么工作的结果一换算法、一调参数就翻车。这一节我把底层逻辑讲清楚你理解之后排查问题会快很多。2.1 从口令到密钥PBE的工作机制Jasypt最常用的场景是PBEStringEncryptor它属于PBE算法。所谓PBE通俗地讲就是你拿一句“口令”password当种子配合一个随机生成的“盐”salt通过哈希算法反复迭代推导出一个真正的对称加密密钥。然后用这个密钥去加密你的明文。盐的作用很关键它让同一段明文在每次加密时生成不同的密文。你可以把盐想象成做菜时的调味料同一块肉每次放的盐量不同成品味道一定不一样。密码学里盐是为了防止攻击者通过预先计算的彩虹表直接反查密文。Jasypt里默认的盐生成器是RandomSaltGenerator每次加密都会生成一段随机盐而解密时必须用同一个盐所以盐会被一并编码进密文里。迭代次数keyObtentionIterations则是为了加大暴力破解的成本。它做的事情就是让“口令盐”反复参与哈希计算次数越多每次加密/解密耗时越长攻击者逐字猜口令的速度也就越慢。默认一般是1000次实际项目里可以按需要调到几千但不要调得太夸张因为每个属性被读取时都会走一遍这个计算。2.2 对称加密与IV生成器密钥推导出来之后真正加密用的是对称加密算法比如DES、AES。老版本的Jasypt默认走PBEWithMD5AndDES这玩意儿在今天看来强度已经偏弱了新版更推荐PBEWITHHMACSHA512ANDAES_256也就是用HMAC-SHA512做密钥派生用AES-256做实际加密。这里还有一个容易忽略的概念IV初始化向量。AES在CBC工作模式下每条密文需要一个随机的IV用来让相同明文生成不同密文。Jasypt对基于AES的算法会默认采用RandomIvGenerator如果你在CLI工具里手动指定了一个IV生成器那么在项目运行时也必须用一致的IV生成器否则解密就会失败。2.3 密文结构长什么样你实际生成的密文是一长串base64或十六进制字符串。如果是PBE算法密文里已经包含了盐、迭代次数相关信息部分由算法标识决定所以解密时才能从密文里提取出盐来重算密钥。举个直观的例子。eJZ4n...这串看起来毫无规律的字符其实就是“盐 IV 加密后的明文”的编码结果。你不需要去解析它但要明白为什么密钥不对就解不出来密钥不同重算出的派生密钥就不同AES解密自然得到一堆乱码Jasypt这时候会直接抛异常而不是给你一个神秘字符串。理解了这个原理你以后再看到配置文件里的ENC(...)就不该把它当成黑盒了——它就是一段包含随机盐、IV、密文的对称加密结果安全性取决于口令强度和算法强度。3. 依赖选型与版本匹配Spring Boot 2.x/3.x怎么选starter集成Jasypt最怕的第一件事就是版本选错具体表现就是依赖加进来项目启动直接报NoSuchMethodError、ClassNotFoundException或者自定义加密器根本没生效。3.1 官方启动器与核心包Spring Boot场景下最省事的做法是用社区维护的jasypt-spring-boot-starter它替你做好了自动配置。Maven坐标如下dependency groupIdcom.github.ulisesbocchio/groupId artifactIdjasypt-spring-boot-starter/artifactId version3.0.5/version /dependency注意starter已经传递依赖了org.jasypt:jasypt核心包一般情况下你不需要手动再加jasypt依赖加了反而可能因为版本冲突出问题。以3.0.5为例它配套的jasypt核心版本是1.9.3对Spring Boot 2.x和3.x都兼容。如果你是在Spring Boot 1.x的老项目里那要用1.x版本的starter比如1.17或1.18。但都2025年了这种老项目大概率也该升Boot 2/3了我就不多展开。3.2 starter到底替你做了一件什么事你可能好奇为什么加一个依赖配置文件里的ENC(密文)就能被自动解密其实是因为这个starter在Spring Boot环境初始化阶段注入了一个EnvironmentPostProcessor它会拦截配置属性解析流程。当Spring读取application.yml或系统环境变量里的属性值时发现值符合ENC(...)格式就调用注入的jasyptStringEncryptor进行解密然后把解密后的值返回给Spring容器。这个设计有个好处它对业务代码完全透明。数据源、Redis、RestTemplate、自定义ConfigurationProperties只要这些属性在启动阶段被真正读取Jasypt就能在背后完成解密。但注意我说的是“真正读取”如果某个属性没被任何Bean使用Jasypt不会去解它这也就引出了后面要讲的“懒解密”坑。3.3 自定义加密器Bean的命名陷阱如果你觉得默认配置不够用想自己写一个加密器Bean那必须把Bean名字定义为jasyptStringEncryptor。starter的自动配置逻辑是先找容器里有没有名字叫jasyptStringEncryptor的StringEncryptor类型的Bean有就用你的没有才创建默认的。很多人自定义的Bean名叫myEncryptor或者stringEncryptor结果发现配置文件里所有ENC(...)都没被解密直接以密文字符串形式传给了数据库连接池报错报得莫名其妙。这属于Spring Boot自动配置“按约定”的典型场景名字错了等于没自定义。另外一点自定义加密器时建议使用PooledPBEStringEncryptor而不是StandardPBEStringEncryptor。池化版本的底层会维护一批加解密线程并发读取多个解密属性时性能更好。这在后面讲性能的时候还会提到。4. 生成密文的四种途径命令行、Java类、测试类、在线工具把Jasypt引入项目之后下一步就是怎么生成密文。我按实用性从高到低排列把这些方法都给你过一遍你挑最顺手的用。4.1 官方命令行工具最正统Jasypt核心包里自带CLI工具类不依赖任何外部框架适合单独使用。假设你已经通过Maven把jasypt核心包下载到了本地仓库可以这样找到jar包java -cp ~/.m2/repository/org/jasypt/jasypt/1.9.3/jasypt-1.9.3.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI input明文内容 password你的口令 algorithmPBEWITHHMACSHA512ANDAES_256执行后会看到类似下面的输出----OUTPUT---------------------- 6U6v3qM9fE2eF/C0JtVpvMJE...这串就是密文。解密命令则是对应的JasyptPBEStringDecryptionCLIjava -cp ~/.m2/repository/org/jasypt/jasypt/1.9.3/jasypt-1.9.3.jar org.jasypt.intf.cli.JasyptPBEStringDecryptionCLI input6U6v3qM9fE2eF/C0JtVpvMJE... password你的口令 algorithmPBEWITHHMACSHA512ANDAES_256需要提醒的是CLI的完整参数名比较长另外input和password如果包含空格、特殊字符在shell里要注意引号转义。Windows的cmd和PowerShell对转义字符的处理还不一样建议用简单的单引号或先写进临时变量。4.2 在测试类里生成最推荐我平时最常用的其实是写一个临时Test方法。这种方式的好处是算法、IV生成器、迭代次数这些参数和项目里的配置天然保持一致不会像手动输CLI命令那样一个参数拼错生成出来就解不开。测试代码长这样import org.jasypt.iv.RandomIvGenerator; import org.jasypt.util.text.BasicTextEncryptor; import org.junit.jupiter.api.Test; class EncryptorTest { Test void generate() { BasicTextEncryptor encryptor new BasicTextEncryptor(); encryptor.setPassword(你的口令); encryptor.setAlgorithm(PBEWITHHMACSHA512ANDAES_256); encryptor.setIvGenerator(new RandomIvGenerator()); String cipher encryptor.encrypt(需要加密的明文); System.out.println(密文 cipher); } }BasicTextEncryptor默认是PBEWithMD5AndDES我上面显式指定了算法和IV生成器这样生成结果就能和后面Spring Boot配置里的参数严格对应。更贴近生产实际的方式是不用BasicTextEncryptor直接用StandardPBEStringEncryptor并设置keyObtentionIterationsStandardPBEStringEncryptor encryptor new StandardPBEStringEncryptor(); encryptor.setPassword(你的口令); encryptor.setAlgorithm(PBEWITHHMACSHA512ANDAES_256); encryptor.setKeyObtentionIterations(1000); encryptor.setIvGenerator(new RandomIvGenerator()); String cipher encryptor.encrypt(需要加密的明文);4.3 注入Spring的StringEncryptor生成项目已经集成好starter之后你其实可以直接注入StringEncryptor这个Bean调用它的encrypt方法。这种方式的好处是你自己不需要关注底层配置细节完全复用项目运行环境的参数SpringBootTest class GenerateCipherTest { Autowired private StringEncryptor stringEncryptor; Test void generate() { System.out.println(stringEncryptor.encrypt(需要加密的明文)); } }代码量最少但我建议在把密文贴进配置文件之前先跑一个decrypt验证一下Test void verify() { String cipher 上一步生成的密文; System.out.println(stringEncryptor.decrypt(cipher)); }能正确解出原文再放到配置里这一步能帮你避开大量算法不一致的坑。4.4 在线工具能不能用网上有不少“Jasypt在线加解密”页面可以输入明文和口令直接出密文。我理解大家的便利性诉求但强烈不建议在生产项目里用在线工具生成正式配置的密文。原因有两个第一你输入的明文比如数据库密码、接口密钥会经过第三方服务器这本身就是一次敏感信息泄露风险第二在线工具的算法、IV生成器和你的项目配置未必一致生成出来的密文经常在本地解不开到时候你还搞不清楚问题出在算法还是盐上。如果只是拿来研究格式或者做个样例那无所谓但生成正式密文请回到本地命令行或测试类方法。5. 在Spring Boot项目中完整接入Jasypt从配置到启动验证前面原理和准备都齐全了这一节直接带你完完整整走一遍接入流程。5.1 第一步引入starter依赖跟第3节一样在pom.xml里加上jasypt-spring-boot-starterdependency groupIdcom.github.ulisesbocchio/groupId artifactIdjasypt-spring-boot-starter/artifactId version3.0.5/version /dependency这里有个实际经验如果项目里已经有Spring Security依赖要留意starter传递进来的依赖冲突最典型的是commons-codec、commons-lang3这些公共库版本被覆盖导致序列化出错。遇到这类问题用mvn dependency:tree查看冲突排除掉旧版本即可不要盲目升级全家桶。5.2 第二步生成密文并替换配置文件先用第4节的测试类方法生成密文。假设我要加密的数据库密码是MyPssw0rd生成的密文是类似6U6v3qM9fE2eF/C0JtVpvMJE...的一长串那我在application.yml里这样写spring: datasource: url: jdbc:mysql://localhost:3306/testdb?useUnicodetruecharacterEncodingutf8 username: root password: ENC(6U6v3qM9fE2eF/C0JtVpvMJE...) jasypt: encryptor: algorithm: PBEWITHHMACSHA512ANDAES_256 password: ${JASYPT_PASSWORD}注意几个细节ENC(...)是Jasypt约定识别的格式括号里面放密文不要画蛇添足加引号或空格。如果密文里包含YAML特殊字符比如冒号、井号、方括号建议用单引号把ENC(...)整体包起来password: ENC(xxx)避免被YAML解析器误认为是复杂键值结构。jasypt.encryptor.password不要硬编码在文件里而是用环境变量${JASYPT_PASSWORD}或启动参数--jasypt.encryptor.passwordxxx传入。密钥写在配置文件里加密的意义就损失大半了。5.3 第三步启动项目验证配好之后直接启动。如果一切正常数据源能连上、Redis连接池能初始化说明解密成功。如果你看到类似DecryptionException: Unable to decrypt的报错按这个顺序排查口令对不对jasypt.encryptor.password和生成密文时的password是否一致。算法对不对生成密文用的算法和配置文件里jasypt.encryptor.algorithm是否一致。IV生成器对不对AES类算法必须使用org.jasypt.iv.RandomIvGenerator没配或配错都会导致解密失败。迭代次数对不对如果你在生成密文时显式设置了keyObtentionIterations那运行环境的jasypt.encryptor.key-obtention-iterations也必须一致否则密钥派生结果不同。5.4 第四步自定义加密器Bean按需默认starter提供的加密器够用但如果你想统一管理多个环境的密钥或想用池化提升性能就在项目里加一个配置类import org.jasypt.encryption.StringEncryptor; import org.jasypt.encryption.pbe.PooledPBEStringEncryptor; import org.jasypt.iv.RandomIvGenerator; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; Configuration public class JasyptConfig { Bean(jasyptStringEncryptor) public StringEncryptor jasyptStringEncryptor() { PooledPBEStringEncryptor encryptor new PooledPBEStringEncryptor(); encryptor.setPoolSize(8); encryptor.setAlgorithm(PBEWITHHMACSHA512ANDAES_256); encryptor.setPassword(System.getenv(JASYPT_PASSWORD)); encryptor.setKeyObtentionIterations(1000); encryptor.setIvGenerator(new RandomIvGenerator()); return encryptor; } }注意两点Bean名字必须叫jasyptStringEncryptor前面讲过原因。另外这里直接把口令从环境变量读取application.yml里就不需要再配置jasypt.encryptor.password了避免两处重复配置导致混淆。5.5 第五步确认哪些属性需要加密不要试图把整个配置文件都加密。Jasypt处理的是String值如果一个ConfigurationProperties里的嵌套对象、List、Map里需要加密某项要保证该项最终是独立可访问的字符串。比如Data ConfigurationProperties(prefix app) public class AppProperties { private String apiKey; private ListString allowIps; }只有apiKey这种标量值适合用ENC(...)包裹allowIps这种集合如果想整体加密Jasypt标准做法是做不到的需要你自定义转换器或用其他加密方案。5.6 第六步验证非敏感属性不受影响Jasypt只会尝试处理匹配ENC(...)格式的值普通明文属性它不会动所以你不必担心误伤普通配置。但我建议在接入后跑一遍全部环境相关的测试用例尤其是数据源连接测试、Redis连接测试、外部接口调用测试确保每个加密属性都能正常解密。6. 上线后最容易踩的坑我挨个排过的雷这一节是真正的经验沉淀。Jasypt用起来虽然不难但在真实项目中会遇到一些文档里很少说明白的问题。6.1 Spring Cloud Config和bootstrap.yml的加密失效如果你用的是Spring Cloud Config且敏感配置是放在bootstrap.yml或者config server返回的远端配置里那jasypt-spring-boot-starter默认的自动配置可能在bootstrap阶段还没生效导致配置中心的属性里如果带ENC(...)解密不了。我遇到的情况是bootstrap.yml里的spring.cloud.config.username和密码没法被Jasypt处理应用启动直接连不上配置中心报认证失败。解决方案有几种把涉及配置中心认证的属性单独用环境变量注入不让它们走配置中心。使用jasypt的bootstrap支持包或者在bootstrap.yml里提前定义好加密器。最稳妥的方案是配置中心只托管非敏感的普通配置连接配置中心本身的凭证用环境变量或部署平台密钥管理来维护不要放进文件里。这个问题在微服务架构下非常典型我建议大家设计阶段就想好Jasypt用于加密“应用自身配置文件里的密钥”而配置中心、K8s Secret、云平台密钥服务这类设施本来就应该承担更上游的密管职责。6.2 懒解密导致的问题Jasypt默认是懒解密只有当某个属性被Spring真正获取时它才会去解密。这带来的坑是如果某个ConfigurationProperties绑定的属性拼写错了或者属性名不匹配Spring永远拿不到这个属性Jasypt自然也不会去解密它。这时候你不会看到解密异常而是得到null、默认值或者绑定失败排查起来绕得很。我在一次上线中遇到过配置类里定义的字段叫redisPassword配置文件里写的却是spring.redis.password启动时Redis没报密码错直到容器真正连接Redis才发现密码是null。后来我改用启动时主动打印所有加密属性是否被成功解密来验证配置映射问题才暴露出来。建议接Jasypt时写一个ApplicationReadyEvent监听器临时打印所有ENC(...)属性的解密结果确认每个加密值都有效。上线后再去掉这个打印防止日志泄露。6.3 密文过长或含特殊字符导致YAML解析异常某些场景下比如加密一个长Token或私钥片段密文会比较长甚至包含/、、这类字符。如果在YAML里不加引号解析器可能把#当注释、把:当键值分隔、把当锚点。最保险的方法就是统一用单引号包起来password: ENC(xxx/yyyzzz)如果密文里还包含单引号本身那就需要双写单引号来转义或者退一步考虑用双引号。这类在YAML层面上的细节看似很low但实际排查起来特别浪费时间。6.4 加密密钥写死在配置文件里的“假安全”我见过不少项目application.yml里直接写着jasypt.encryptor.password: mySecretKey然后拿这个密钥加密了一堆数据库密码。这属于典型的“把钥匙挂在门口脚垫下”如果攻击者拿到了你的配置文件他同时拿到了密钥解密就是分分钟的事。正确的做法是本地开发时在IDE的启动环境变量里配置JASYPT_PASSWORD。测试/生产环境在部署平台的配置项里配置环境变量或在启动脚本里以-Djasypt.encryptor.passwordxxx方式传入。CI/CD流水线里用密钥管理平台注入不要写死在Jenkinsfile或Dockerfile里。6.5 老算法下线问题如果你公司项目从老版本Jasypt升级或者换了一套加密算法那之前生成的一批密文会全部失效因为算法变了解密时走不通。这时候你有两个选择一是保留旧的加密器配置同时新建一个新的加密器Bean然后逐步把配置项迁移到新算法二是直接一次性换掉所有密文但这个过程要保证应用是停机维护的。我在实际项目里遇到过最坑的是明明开发环境都正常到了生产环境一批ENC(...)值解不开后来发现是生产环境JDK版本比开发环境老对PBEWITHHMACSHA512ANDAES_256这种较新的算法支持不完整。解决办法是统一JDK版本或换用更兼容的PBEWithMD5AndDES当然权衡一下安全性。6.6 PooledPBEStringEncryptor带来的线程池异常自定义加密器时用了PooledPBEStringEncryptor但setPoolSize设得过大比如16、32在低配机器上启动时会出现线程创建失败或GC压力。实测下来常规Spring Boot单体应用设4到8就够了没必要贪多。PBE加解密本身就是CPU密集线程池太大只会加剧上下文切换不会提升线性吞吐。6.7 加密属性在单元测试里的前置条件如果你的测试类里用SpringBootTest启动了整个Spring容器而测试环境没有配置JASYPT_PASSWORD环境变量那容器启动时属性解析就会失败。解决办法是给测试环境单独提供测试密钥或者用TestPropertySource指定TestPropertySource(properties { jasypt.encryptor.passwordtest-only-key })但这样会造成测试环境密钥和生产不一致所以只适合用来跑功能测试别把生产数据带到测试里解密。6.8 日志中泄露明文配置有些团队在启动时会把配置中心拉下来的整个配置打印出来用于排错这等于把Jasypt的功夫全废了。如果一定要打印配置至少要把密码字段打码后再输出或者把敏感字段排除在/actuator/env等接口的展示范围之外。7. 密钥管理、性能调优与多环境设计让Jasypt用得长久把Jasypt跑通只是一步真正能不能在生产环境稳定用下去还得看密钥管理和性能设计。7.1 密钥放在哪里最合适按优先级排序我推荐部署平台的环境变量K8s Env、容器服务配置云厂商的密钥管理服务KMS/Secrets Manager启动脚本里的-D参数配合CI/CD的密钥注入本地开发的IDE环境变量无论哪种核心原则是密钥不能进代码库不能进镜像层不能进可以被应用日志打印出来的地方。还有一个容易被忽略的点应用异常时如果抛出DecryptionException异常信息里不会包含密钥本身但包含算法名和参数这类日志可以放心给运维看。7.2 密钥轮换怎么做密钥轮换是安全运维绕不开的话题。Jasypt的密文是单向绑定密钥的你换了密钥旧密文就解不开了。所以轮换流程一般是准备新密钥让应用支持同时在环境变量中读取新旧两套密钥。用新密钥重新加密所有敏感配置生成新密文。在低峰期重启应用让新配置生效。确认业务无异常后再回收旧密钥。如果不想停机轮换可以用类似Spring Cloud Config Server的encrypt/decrypt接口配合Jasypt做在线变更但这对架构复杂度要求高。大多数情况下支持双密钥并存的方案就够用了。7.3 性能调优别让Jasypt成为启动瓶颈Jasypt的加解密计算集中发生在Spring容器初始化阶段理论上会影响启动速度但对运行期影响极小因为配置属性一般在Bean初始化时就读取完。真遇到启动变慢优先检查这几个点是否使用了PooledPBEStringEncryptor并合理设置池大小。keyObtentionIterations是否过大超过5000次迭代每个属性都会明显拖慢。是否有大量属性都用了ENC(...)但实际只需要加密两三个敏感项。是否在PostConstruct或者循环依赖场景里频繁触发解密。我在一个老项目里见过有人把几十个配置项全部加密导致每次启动要多花三四秒。后来只保留真正敏感的六个属性启动恢复到了秒级。这说明加密的粒度也是性能设计的一部分。7.4 多环境下的配置差异开发、测试、生产环境的密钥应该不同。否则一个开发环境的密钥泄露直接导致生产密文全部可解。我用Jasypt时习惯这样管理每个环境一个环境变量名比如DEV_JASYPT_PASSWORD、PROD_JASYPT_PASSWORD然后在启动脚本里映射为统一的JASYPT_PASSWORD。每个环境用自己的密钥重新生成自己的密文保证开发环境的密文拿到生产环境是解不开的。生产环境的密文只存在生产分支的配置仓库里开发分支的配置是另一套值。7.5 Jasypt之外我还做了什么实话实说光有Jasypt并不能防住所有安全风险。我在项目里还会做这几件事在代码扫描阶段检查有没有明文密钥提交。对数据库账号做最小权限授权即使配置泄露影响范围也在可控范围内。开启审计日志记录谁访问了敏感配置。运维侧限制生产服务器的访问权限。这些跟Jasypt是互补关系不是替代关系。最后分享一点实操心得我不太爱写总结性的东西就讲两个项目中淬炼出来的小经验吧。第一所有密文在正式提交到代码库之前先在本地写一个decrypt(密文)的测试跑通。我碰到过太多人拿着CLI生成的密文粘贴到配置文件后启动失败最后发现是命令行参数里的stringOutputType和项目配置不一致。多跑一步解密验证这类问题能当场排除掉。第二不用害怕ENC()括号里的密文偶尔包含特殊字符但它看起来不像密码了但一定不要因为“看着不像密码”就放松对配置文件的访问控制。Jasypt只是提高了信息泄露的利用门槛真正扛住安全风险靠的还是环境隔离、密钥隔离、最小权限这些组合拳。如果你正在为Spring Boot项目里的明文密码头疼花上一个小时把Jasypt接进来是今天就能做完、明天就能见效的投资。数据源密码、Redis密码、第三方密钥全都可以交给它守护配置文件从此经得起“翻”了。