不推荐用动态代理拦截Map接口实现敏感数据加解密，因其易破坏Map语义、干扰框架行为、泛型擦除致误判、无法区分出入参且不覆盖JSON/DTO/实体等主流载体；应分层治理：数据库层用MyBatis拦截器、接口层用Spring MVC参数解析器、序列化层用Jackson定制处理器。
直接用动态代理拦截 map 接口方法来实现敏感键值对的自动加解密，**不推荐用于生产环境**。这不是技术不可行，而是它在真实系统中存在严重隐患：易破坏 map 语义、干扰框架行为、难以兼容泛型与并发场景，且无法覆盖主流数据载体（如 json、dto、数据库实体）。
为什么 Map 动态代理方案在生产中风险高
Java 中的 Map 是高度泛用的基础接口，Spring、MyBatis、Jackson 等几乎所有主流框架都依赖其原生行为。一旦对其做全局代理：
- 所有
put("phone", "138****1234")调用都可能被拦截并加密，但下游若期望明文（如日志打印、参数校验、缓存 key 计算），就会出错 -
HashMap、LinkedHashMap、ConcurrentHashMap的内部优化（如红黑树转换、CAS 操作）可能被代理层绕过或破坏 - 泛型擦除导致运行时无法准确识别“哪些 key 对应敏感字段”，只能靠字符串匹配，极易误判（如把
"password_reset_token"当作密码加密，实际它是临时凭证） - 无法区分“入参 Map”和“返回 Map”——加密后返回给前端，前端根本无法解密；而解密逻辑又不该出现在客户端
真正适合生产的替代路径
敏感数据加解密必须**分层治理、按场景选点**，而不是强行统一拦截 Map：
-
数据库读写层（首选）：用 MyBatis 拦截器 +
@SensitiveField注解，在ParameterHandler入参时加密、ResultSetHandler出参时解密。业务代码完全无感，支持实体类、List<Map>、嵌套对象等全部参数类型 -
HTTP 接口层（传输安全）：用 Spring MVC 的
HandlerMethodArgumentResolver和ResponseBodyAdvice，对 Controller 入参/出参中的特定字段（如 DTO 内的idCard）做加解密，不碰底层 Map -
序列化层（防日志/调试泄露）：用 Jackson 的
@JsonSerialize/@JsonDeserialize或自定义SimpleModule，仅在 JSON 序列化/反序列化时脱敏或加解密，不影响内存中对象状态
如果非要代理 Map，只限极小范围可控场景
例如：某个内部工具类明确封装了“仅用于配置加载的敏感配置 Map”，且生命周期短、不跨线程、不进框架栈。此时可谨慎使用 JDK 动态代理：
- 代理目标必须是接口（
Map.class），不能是具体实现类（如HashMap.class） - 只重写
put(K,V)和get(Object)，其他方法（如entrySet()、keySet()）直接委托，避免破坏迭代逻辑 - 加解密规则必须白名单驱动：
private static final Set<String> SENSITIVE_KEYS = Set.of("api_key", "db_password"); - 密钥不得硬编码，须从 Spring Environment 或 Vault 获取，且禁止在 toString() 中暴露密文
本质上，加解密不是“在哪里拦”，而是“在哪一层、对哪一类数据、按什么策略、由谁负责”。Map 代理只是技术玩具，生产系统要的是可审计、可灰度、可回滚的分层防护机制。
