connection必须实现autocloseable才能用于try-with-resources，旧驱动（如mysql 5.1.x、postgresql 42前）仅实现java.sql.connection而未实现autocloseable，导致编译报错；需升级驱动并确保jdk≥7、编译目标设为1.7+。
Connection 必须实现 AutoCloseable 才能进 try-with-resources
直接把 Connection 放进 try 括号里报错，大概率是驱动太老。MySQL 5.1.x、PostgreSQL 42 之前的旧驱动中，Connection 只实现了 java.sql.Connection，没实现 AutoCloseable——编译器会直接拒绝，提示 “resource type does not implement AutoCloseable”。
实操建议：
- 检查当前驱动版本：
System.out.println(com.mysql.cj.jdbc.Driver.class.getPackage().getImplementationVersion()) - MySQL 必须升级到 Connector/J 8.0+（JDBC 4.2 兼容）
- PostgreSQL 推荐用 42.7+（明确声明支持 JDBC 4.1+）
- 确认项目
source和target均设为1.7或更高（Maven 中maven.compiler.source）
别只关 Connection，Statement 和 ResultSet 也得一起声明
只写 Connection 是常见误区。如果只关连接，而 PreparedStatement 或 ResultSet 仍被持有（尤其大结果集未遍历完），可能触发连接池告警：“connection returned without closing all resources”，甚至导致连接无法归还。
正确做法是把整条链路资源都放进资源列表，按声明顺序逆序关闭：
- 顺序必须是：先
ResultSet，再PreparedStatement，最后Connection（虽然编译器不强制顺序，但逻辑上更安全） - 所有资源必须在 try 括号内完成初始化，不能提前赋值为
null或复用外部变量 - 避免在 try 块内对资源重新赋值（比如
rs = stmt.executeQuery("...")再赋一次），否则旧对象不会被自动关闭
示例片段：
try (Connection conn = dataSource.getConnection();
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?");
ResultSet rs = stmt.executeQuery()) {
while (rs.next()) {
System.out.println(rs.getString("name"));
}
} catch (SQLException e) {
// 异常处理
}
异常发生时 close() 仍会被调用，但 suppressed exception 容易被忽略
try-with-resources 确保无论正常结束还是抛异常，每个资源的 close() 都会被执行。但如果 try 块本身已抛出异常（如 SQLTimeoutException），而某个 close() 又抛出新异常（如网络中断导致连接关闭失败），后者不会覆盖主异常，而是作为 suppressed exception 附加在主异常上。
这意味着：
-
e.printStackTrace()默认不打印 suppressed 异常，需显式调用e.getSuppressed()查看 - 日志框架（如 Logback）默认也不记录 suppressed 异常，需配置或手动 log
- 连接池（如 HikariCP）在
close()失败时通常会 warn 日志，但不会阻断流程——这容易掩盖底层网络问题
使用连接池时，close() 实际是归还连接，不是物理断开
很多人误以为 conn.close() 在连接池环境下真断开了 TCP 连接。其实它只是把连接对象标记为空闲并放回池中。真正物理关闭发生在连接空闲超时、池收缩或 JVM 退出时。
所以要注意：
- 即使用了 try-with-resources，若连接池配置不当（如
maxLifetime过长、idleTimeout过大），仍可能导致连接长期占用、数据库端游标堆积 - 某些池（如 Druid）提供
removeAbandonedOnBorrow等机制来回收疑似泄漏的连接，但这属于兜底策略，不能替代正确声明资源 - 如果业务需要强制物理断开（如切换数据库实例），得调用池特有 API（如 HikariCP 的
evictConnection()），而非依赖close()
最易被忽略的一点：资源声明必须严格匹配使用范围。跨方法传递 Connection 或在 try 块外保存 ResultSet 引用，会让 try-with-resources 彻底失效——它只管自己括号里声明、初始化、且未被重新赋值的对象。
