Spring JDBC中StatementCallback异常需显式捕获并转为RuntimeException，否则被UndeclaredThrowableException掩盖；应埋点日志、校验结果集、显式关闭资源，并配置异常翻译、连接池监控与异步补偿。
当你在Spring JDBC中使用StatementCallback执行SQL时遇到异常中断、日志无堆栈、事务未回滚或结果集丢失等问题，说明回调内部发生了未捕获的错误——这类错误不会自动传播到外层，极易导致静默失败。
定位回调内异常源头
第一步：在回调函数入口处添加最小化日志埋点，用Logback或Loguru记录进入时间与参数摘要。不要只打“开始执行”，要输出SQL片段和关键参数值，否则无法区分是哪次调用出的问题。
第二步：检查是否在回调中直接调用了可能抛出受检异常（如IOException）却未声明throws或包裹try-catch。Spring的StatementCallback接口不声明异常，【所有受检异常必须在回调体内显式捕获并转换为RuntimeException】，否则JVM会强制包装成UndeclaredThrowableException，掩盖原始错误类型。
第三步：用IDE调试模式在doInStatement方法断点处单步步入，重点观察ResultSet.next()、getXXX()、close()三处——80%的StatementCallback崩溃发生在这三个调用上，尤其是对空结果集调用getString(1)或对已关闭连接调用executeQuery()。
修复常见执行型回调错误
方法一：针对SQL执行阶段异常（如语法错误、表不存在）
在executeQuery()外层加try-catch，捕获SQLException并封装为自定义业务异常（如DataAccessException子类），避免原始SQL暴露在日志中。不要用printStackTrace()，改用logger.error("SQL执行失败 | SQL: {}", maskedSql, e)。
方法二：针对结果集解析异常（如类型转换失败、列索引越界）
用ResultSetMetaData校验列数与类型再取值：rs.getMetaData().getColumnCount() > 0确保有数据；rs.getMetaData().getColumnTypeName(1).contains("VARCHAR")再调用getString(1)。这一步能提前拦截90%的ClassCastException。
方法三：针对资源泄漏引发的后续回调崩溃
务必在finally块中显式关闭ResultSet和Statement，即使Spring模板通常会代理关闭——当回调内手动创建了Statement或ResultSet时，Spring无法接管生命周期。漏关会导致连接池耗尽，下一次回调直接卡死在getConnection()。
配置全局兜底与可观测性
① 在JdbcTemplate Bean初始化时注入自定义SQLExceptionTranslator，将数据库特有错误码（如MySQL 1062主键冲突、PostgreSQL 23505唯一约束）映射为语义明确的业务异常，避免上层代码面对GenericJDBCException无所适从。
② 使用@Scheduled每5分钟扫描一次DataSource的activeCount，超过阈值时触发告警并dump当前所有StatementCallback调用栈——很多内存泄漏问题在运行2小时后才暴露，靠单次日志无法发现。
③ 对关键回调（如支付扣款、库存锁定）启用异步补偿监听器：当回调返回null或抛出特定异常时，自动向消息队列投递重试任务，并附带原始SQL哈希与参数快照，供人工核对。
