无侵入式加密技术的核心思想
说实话，我第一次接触“无侵入式加密”这个概念时，脑子里就两个字：不碰业务代码？那怎么加密？
后来在项目里踩过坑才明白——**无侵入式的本质，是把加密逻辑从业务代码里彻底剥离出去，放到一个独立的拦截层里。** 业务代码该干嘛干嘛，完全不知道自己被加密了。
什么叫“侵入式”？先看反面例子
我猜你肯定见过这样的代码：
// 侵入式：每个方法都要手动加解密
public void saveUser(User user) {
String encryptedName = AESUtil.encrypt(user.getName());
user.setName(encryptedName);
userDao.insert(user);
}每个数据操作都写一次加解密调用。改算法？得改几十个文件。换密钥？得重新部署。这就是典型的侵入式——加密逻辑和业务逻辑耦合在一起，像米和沙子搅匀了分不开。
核心思想一句话：让业务代码完全不知道加密的存在，加密是基础设施的事，不是业务的事。
无侵入式怎么做到的？
说白了，就是找一个人替业务代码干活。谁？拦截器/代理/中间件。它在数据进入持久层之前截住，干完加密放行；在数据从数据库返回时再截住，解密后传递给业务。
我在项目中做过一个典型做法——基于 MyBatis 的 Interceptor：
@Intercepts({
@Signature(type = ParameterHandler.class, method = "setParameters", args = {PreparedStatement.class})
})
public class EncryptInterceptor implements Interceptor {
@Override
public Object intercept(Invocation inv) throws Throwable {
// 获取参数对象
Object param = inv.getArgs()[0];
// 判断是否需要加密（通过注解或者配置）
if (needEncrypt(param)) {
encryptFields(param); // 只加密敏感字段
}
return inv.proceed();
}
}你想想看，业务层调用 userDao.insert(user)，里面存的 name 已经是密文了。业务代码一行没改，但数据库里存的是密文。这就是无侵入。
小经验：我个人习惯用注解（比如 @SensitiveField）标记需要加密的字段，而不是全局全量加密。全量加密会破坏索引和查询，容易出坑。
侵入式 vs 无侵入式 对比
| 对比维度 | 侵入式 | 无侵入式 |
|---|---|---|
| 业务代码改动 | 每个方法手动加解密 | 零改动 |
| 加密逻辑位置 | 散落在业务代码中 | 集中在一个拦截层 |
| 密钥更换 | 需要修改代码+重新部署 | 只需修改配置（HSM协商） |
| 算法升级 | 大面积改代码，容易遗漏 | 替换拦截层实现，一行不动业务 |
| 可审计性 | 难以统一管控 | 所有加密行为在拦截层有日志 |
| 对性能影响 | 较难定位瓶颈 | 容易做性能分析（单一入口） |
几个关键设计原则
- 业务代码零感知：加密行为不能暴露给业务层，不能要求业务代码传递密钥或选择算法。
- 密钥管理外部化：密钥不落在代码里，通过配置中心或HSM动态获取。我曾经见过有人把密钥写在配置文件里提交到Git——那和没加密没啥区别。
- 敏感字段可配置：哪些字段加密、用什么算法、什么密钥版本，都要能在外部配置中声明。
- 拦截点选择：通常在ORM层（MyBatis、Hibernate）、RPC调用层（Dubbo Filter）、或者数据库驱动层做拦截。
- 完美支持HSM：加密操作直接调用HSM的API，业务代码完全不感知硬件存在。
避坑指南：我曾经在一个项目中把加密拦截放到了AOP的Service层，结果遇到Service方法内调用另一个Service方法的场景，AOP内部调用不经过代理，导致数据没加密直接入库。解决方案：要么把拦截点放到ORM层（更底层），要么在Spring配置中强制使用代理目标暴露。
无侵入式加密的典型架构图
这张图展示了核心思想：业务代码只跟拦截层打交道，拦截层负责加解密，密钥和配置则来自外部服务。业务代码根本不知道数据被加密了——这就是无侵入。
什么时候适用？什么时候别用？
- 适合：已有系统需要加密改造，但又不能大规模改业务代码。或者新系统想保持业务纯粹，把加密当成基础设施。
- 不适合：加密逻辑需要根据业务上下文动态变化（比如根据用户等级选择不同算法），这种场景侵入式反而更直接。
- 注意：无侵入加密对性能有一定影响（多了一层拦截），但通常是可以接受的。我在项目中测过，MyBatis Interceptor方式每个insert大约增加0.3ms，对大部分业务无感。
一个实用的判断方法：如果加密逻辑在项目后期才加入，或者可能频繁变更（比如因合规要求），无侵入式几乎是唯一的选择。如果你在项目一开始就有清晰的加密规划，且业务层本身也愿意承担少量耦合，侵入式也可以接受。我个人倾向——能用无侵入就用无侵入，将来改起来省心。
小结
无侵入式加密的核心就三件事：剥离、拦截、外部化。剥离加密逻辑与业务代码的耦合；在合适的拦截点悄无声息地干活；将密钥和配置推向外部服务。做到了这三点，你的系统加密就像加了一层透明护甲——业务代码安心写业务，加密交给基础设施。后面我会拿一个真实HSM对接案例，一步步拆解具体怎么落地。