Java通用日志注解审计JDBC需：定义含开关与分类的注解→AOP切JDBC执行层（如MyBatis Executor或JdbcTemplate底层）→安全拼装带脱敏参数的SQL→异步批量落库并规避事务回滚、敏感信息泄露等风险。
Java 中设计通用日志注解来拦截 JDBC 参数并异步写入 MySQL 审计表，核心在于：用自定义注解标记方法 → 用 AOP 切面捕获执行上下文 → 解析 JDBC 执行的 SQL 和参数 → 异步落库。关键难点不在“记录”，而在“安全、准确、低侵入地拿到真实 SQL 和参数”。
定义可复用的审计日志注解
注解需支持开关控制、分类标识和自定义业务标签：
- 使用 @Target({ElementType.METHOD}) 和 @Retention(RetentionPolicy.RUNTIME)
- 添加 value() 字段用于标识操作类型（如 "USER_LOGIN", "ORDER_CREATE"）
- 添加 enabled() 布尔字段，方便动态关闭某类审计（避免全量日志压垮 DB）
- 不建议在注解中放敏感字段（如 user_id），应由切面从上下文（如 SecurityContext 或 ThreadLocal）提取
用 Aspect 拦截 DAO/Service 层方法并获取 JDBC 执行细节
单纯拦截 Service 方法只能拿到方法签名和入参，拿不到实际执行的 SQL 和参数。真正要审计的是 JDBC 层行为，所以切点应设在 JdbcTemplate、MyBatis 的 Executor 或 DataSourceUtils 等更靠近执行的位置：
- 若用 MyBatis：切 org.apache.ibatis.executor.Executor.update() / query()，通过 MappedStatement 获取 SQL 模板，用 parameterObject + boundSql.getParameterMappings() 提取参数值
- 若用 JdbcTemplate：重写或代理 PreparedStatementCreator，或在 Connection.prepareStatement() 后通过反射读取 PreparedStatement 内部参数（如 HikariCP 的 ProxyConnection 可获取原始 PreparedStatement）
- 避免直接切 @Transactional 方法——事务未提交时参数可能被修改，且无法区分是 insert 还是 update
安全拼装可审计的 SQL（带参数值）并异步入库
不能直接把原始 SQL + Object[] 参数丢进日志——有 SQL 注入风险，且 JSON 序列化可能失败。正确做法是：
立即学习“Java免费学习笔记（深入）”；
- 用 org.apache.commons.text.StringSubstitutor 或手写简单占位符替换逻辑，把参数安全填入 SQL 模板（字符串转义、数字/布尔直填、null 标记为 NULL）
- SQL 长度超 2000 字节时截断并加标识（如 "...[TRUNCATED]"），防止字段溢出
- 异步用 CompletableFuture.runAsync(..., auditExecutor) 提交，线程池需独立配置（避免挤占业务线程），拒绝策略建议记录到本地文件备用
- 审计表字段建议含：id, trace_id, op_type, sql_full, params_json, exec_time_ms, status（success/failed）, error_msg, create_time
规避常见坑点
这个方案看似简单，实操中容易翻车：
- 事务未提交就记录：SQL 执行成功但事务回滚了，审计日志却留下了“假操作”。解决方案：监听 TransactionSynchronizationManager，在 afterCommit() 回调里真正落库
- 参数含敏感信息：手机号、身份证号等必须脱敏（如 138****1234）。在拼装前对 key（如 "idCard"、"phone"）做白名单匹配 + 正则掩码
- 高并发下审计表写入慢拖累主流程：启用批量插入（如每 50 条 flush 一次）、或先写 Kafka/Redis 再由单独消费者落库
- MyBatis 动态 SQL 的参数位置错乱：不要依赖 ParameterMapping 的顺序，改用 BoundSql.getAdditionalParameters() + getParameterObject() 联合解析
