传统jdbc编程存在代码冗余、sql与java强耦合、资源管理繁琐、结果映射手动化、缺乏缓存及事务管理复杂等痛点，导致开发效率低、维护成本高、易出错。
Java 中传统 JDBC 编程的常见痛点，核心在于“手工操作太多、耦合太紧、容错太弱”。它把数据库底层细节直接暴露给业务代码，导致开发效率低、维护成本高、出错概率大。
连接管理繁琐且易泄漏
每次查询都要手动加载驱动、获取 Connection、再显式 close，稍有疏忽（比如在异常分支中漏关 ResultSet 或 Connection），就会引发连接泄漏，最终拖垮数据库。连接频繁创建销毁还消耗大量资源，尤其在高并发下极易触发连接池耗尽。
- 硬编码数据库地址、用户名、密码，改配置就得重编译
- 没有统一入口管理连接生命周期，不同 DAO 类各自 new Connection
- finally 块里嵌套多层 close 判断，代码臃肿还容易写错顺序
SQL 与 Java 代码高度耦合
SQL 写死在字符串里，参数靠 setInt、setString 硬编码位置，结果靠 rs.getString("name") 手动取值——一旦表字段改名、增删列，所有相关 Java 方法全得跟着改，牵一发而动全身。
- where 条件动态拼接容易出错，也埋下 SQL 注入风险
- 同一条 SQL 在多个方法中重复出现，违反 DRY 原则
- 无法对 SQL 进行集中版本管理或语法校验
结果映射完全手动，扩展性差
从 ResultSet 逐字段取出数据、new 对象、赋值，每张表、每个查询都写一遍类似逻辑。遇到关联查询、嵌套对象、空值处理，代码更复杂，也更容易漏判 null 导致 NPE。
- 字段名和 Java 属性名不一致时，必须写别名或强依赖数据库命名习惯
- 集合类（如 List
）需要手动 while(rs.next()) 循环封装 - 没有类型安全检查，rs.getInt("id") 实际返回字符串会直接抛异常
事务和异常处理全靠手写
开启事务要 conn.setAutoCommit(false)，提交要 conn.commit()，回滚要 conn.rollback()，还要包在 try-catch 里——一个业务涉及多个 DAO 调用时，事务边界难控制，异常吞掉后连日志都看不到。
- SQLException 是受检异常，强制 try-catch，但多数场景只是打印堆栈，没做真正恢复
- 跨方法调用时，事务无法自动传播，容易出现部分成功部分失败的数据不一致
- 没有统一的异常翻译机制，数据库特有错误码（如 MySQL 的 1062 主键冲突）难以友好提示
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
