try-catch不能防范sql注入，仅能间接防护：捕获具体sqlexception、脱敏错误信息、用try-with-resources释放资源、封装为业务异常向上抛出。
try-catch 本身不能防范 SQL 注入，它只能处理注入已发生后抛出的异常；真正防范注入要靠 PreparedStatement、输入校验等前置手段。但合理使用 try-catch，能防止注入触发的 SQLException 导致程序意外崩溃或信息泄露——这是“间接防护”的关键。
捕获具体异常，不吞掉 SQLException
SQL 注入若未被拦截，常导致 SQLException（如语法错误、表不存在、列名非法），这类异常是受检异常，必须显式处理。不能用 catch (Exception e) 一锅端，更不能空 catch：
- 单独捕获 SQLException，并做差异化响应：连接失败走降级逻辑，语法错误说明输入异常，应记录并拒绝请求
- 避免 catch (Throwable e) 或 catch (Error e)，它们可能掩盖 JVM 级故障
- 不写 catch (SQLException e) { /* 什么也不做 */ }——这等于让错误静默传播，后续空指针或状态错乱更难排查
异常处理中屏蔽敏感细节
SQLException 的 getMessage() 常含数据库类型、表名、字段名、驱动版本等敏感信息，直接返回前端或记入公开日志等于帮攻击者测绘系统：
- 对前端返回统一提示，如 "操作失败，请稍后重试"，绝不拼接 e.getMessage()
- 记日志时优先用 e.getSQLState()（如 "42S02" 表示表不存在）和 e.getErrorCode()（数据库特有码），它们标准化、无上下文
- 禁用 e.printStackTrace() 写入生产日志；如需堆栈，用 SLF4J 的 logger.error("DB query failed", e)，确保脱敏配置生效
配合资源管理，避免连锁崩溃
注入引发异常时，若数据库连接、ResultSet 等未释放，可能快速耗尽连接池，导致后续所有请求超时崩溃：
- 强制使用 try-with-resources：Connection、PreparedStatement、ResultSet 都实现 AutoCloseable，JVM 保证异常下也自动关闭
- 不要在 finally 中手动 close 并忽略新异常；更不要在 finally 里 return 或 throw ——会覆盖原始 SQLException
- 若需清理非 AutoCloseable 资源（如自定义锁、缓存标记），在 catch 后明确处理，并确保不抛出新异常干扰主流程
向上封装为业务异常，隔离影响范围
原始 SQLException 对业务层无意义，且暴露技术栈。应将其转为带语义的运行时异常，交由全局处理器统一管控：
- 定义如 DataAccessException extends RuntimeException，构造时传入错误码（如 "SQL_VALIDATION_FAILED"）、关键参数（userId、orderId）和原始异常
- 在 DAO 层 catch SQLException 后，立即封装抛出，不留在 service 层处理
- Spring 项目可配 @ControllerAdvice 拦截该异常，返回标准 JSON（如 { "code": 5001, "msg": "数据操作异常" }），前端按 code 分类提示
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
