在使用原生JDBC进行数据库开发时，最让人头疼的环节往往不是建立连接或执行SQL，而是把ResultSet中的数据一行行取出来，再逐个字段封装到实体类中。一个有二十个字段的表，就要写二十行rs.getString或rs.getInt，代码冗长且容易出错。Lambda表达式为这个问题提供了一个优雅的解法：我们可以把「一行记录如何转换成对象」这件事抽象成一个函数，由调用方以Lambda的形式传入，从而实现一次封装、处处复用的通用查询方法。
一、传统ResultSet封装写法的问题
先来看一段典型的传统写法。假设有一个User实体类，包含id、name、age、email四个字段，查询时通常这样写：
List<User> users = new ArrayList<>();
String sql = "SELECT id, name, age, email FROM t_user";
try (Connection conn = DriverManager.getConnection(url, user, pwd);
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql)) {
while (rs.next()) {
User u = new User();
u.setId(rs.getInt("id"));
u.setName(rs.getString("name"));
u.setAge(rs.getInt("age"));
u.setEmail(rs.getString("email"));
users.add(u);
}
} catch (SQLException e) {
e.printStackTrace();
}这段代码的问题很明显。第一，字段映射逻辑与流程控制代码混在一起，while循环、异常处理、资源关闭等样板代码把真正的业务逻辑淹没了。第二，如果另一个地方要查询同样的表但只封装部分字段，代码几乎要整个复制一遍，违反了DRY原则。第三，一旦实体类字段增多，这段代码会线性膨胀，任何新增字段都要人工同步修改，遗漏了就是隐蔽的bug。
更深层的问题在于，这段代码中真正「每次都不一样」的部分，只有while循环体里的那几行setXxx调用。如果我们能把这部分可变的逻辑抽取出来，把固定的流程部分固化成通用方法，就能实现复用。这正是Lambda表达式的用武之地。
二、用函数式接口抽象行映射逻辑
Lambda表达式的本质是把行为当作数据传递。要利用它，首先需要定义一个函数式接口，用来描述「一行ResultSet如何变成一个T对象」这个行为。借助泛型，这个接口可以适配任何实体类型：
@FunctionalInterface
public interface RowMapper<T> {
T mapRow(ResultSet rs, int rowNum) throws SQLException;
}有了RowMapper之后，我们就可以编写一个通用的查询方法。这个方法负责连接管理、语句执行、结果集遍历这些固定流程，而把行映射交给外部传入的Lambda：
public static <T> List<T> query(String sql, RowMapper<T> mapper) throws SQLException {
List<T> result = new ArrayList<>();
try (Connection conn = DbUtil.getConnection();
PreparedStatement ps = conn.prepareStatement(sql);
ResultSet rs = ps.executeQuery()) {
int rowNum = 0;
while (rs.next()) {
result.add(mapper.mapRow(rs, rowNum++));
}
}
return result;
}注意这个设计的巧妙之处：mapRow方法声明抛出SQLException，这样Lambda体内可以直接调用rs.getXxx而不需要try-catch包裹，因为SQLException会沿着调用链向上传播，由通用方法的调用方统一处理。如果用java.util.function包里的内置函数式接口（比如Function），它们不允许抛出受检异常，反而会带来额外麻烦，所以自定义接口是更合适的选择。
调用时的代码量缩减非常可观：
List<User> users = query(
"SELECT id, name, age, email FROM t_user WHERE age > ?",
(rs, i) -> {
User u = new User();
u.setId(rs.getInt("id"));
u.setName(rs.getString("name"));
u.setAge(rs.getInt("age"));
u.setEmail(rs.getString("email"));
return u;
}
);虽然映射逻辑本身还写着，但它已经被隔离到一个独立、纯粹、可读的Lambda表达式中，与流程代码彻底解耦。实际上，Spring JdbcTemplate中的query方法正是采用这一设计思路，RowMapper接口在Spring中也是真实存在的，这说明该模式经过了大规模生产环境验证。
三、结合泛型与Stream API进一步优化
在RowMapper的基础上，还可以再向前走一步。对于单条记录查询，可以封装一个返回Optional的方法，用Stream API把整个流程串联起来：
public static <T> Optional<T> queryOne(String sql, RowMapper<T> mapper) throws SQLException {
return query(sql, mapper).stream().findFirst();
}对于统计类查询，也可以定义一个针对单值的简化版本，省去创建实体类的开销：
public static long queryCount(String sql) throws SQLException {
try (Connection conn = DbUtil.getConnection();
PreparedStatement ps = conn.prepareStatement(sql);
ResultSet rs = ps.executeQuery()) {
rs.next();
return rs.getLong(1);
}
}如果多个查询返回的实体映射逻辑相同，还可以把Lambda提取成一个静态常量或静态方法引用，实现真正的复用。例如把User的映射逻辑定义为public static final RowMapper<User> USER_MAPPER = ...，所有查询User的地方都引用同一个常量，字段变更时只需修改一处。此外，配合方法引用语法，对于字段名与列名完全一致且使用下划线命名的场景，甚至可以借助反射写一个通用的BeanRowMapper，不过反射方案在性能敏感场景下需要谨慎评估，必要时可以加缓存优化。
四、异常处理与资源释放的注意事项
使用Lambda封装JDBC操作时，有几个容易踩坑的点需要格外注意。首先是ResultSet的作用域问题。Lambda只在mapRow方法内拿到ResultSet，此时结果集仍然有效；但绝不能把ResultSet本身存入Lambda外部让它在try-with-resources块结束后继续使用，因为连接关闭后ResultSet也随之失效，再调用getXxx会抛出SQLException。正确的做法是始终在mapRow内部完成数据提取，只把封装好的对象传出。
其次是受检异常的处理。由于RowMapper声明了throws SQLException，Lambda内可以放心调用JDBC API，但整个通用方法最终仍会抛出SQLException给上层。建议在数据访问层把SQLException统一转换成自定义的运行时异常（例如DataAccessException），这样上层业务代码不必到处写throws声明，事务边界也更加清晰：
public static <T> List<T> querySafe(String sql, RowMapper<T> mapper) {
try {
return query(sql, mapper);
} catch (SQLException e) {
throw new DataAccessException("查询失败: " + sql, e);
}
}最后是资源释放。通用方法内部务必使用try-with-resources保证Connection、PreparedStatement、ResultSet三者的关闭顺序正确。如果连接来自连接池，还要确保连接的获取与归还都封装在工具类内部，避免Lambda调用方直接触碰连接对象，否则一旦某处忘记关闭，连接泄漏会让连接池迅速耗尽。
总结来说，Lambda表达式在这里发挥的核心作用是「行为参数化」：把最易变的行映射逻辑作为参数传入固化的流程模板，用极小的改动成本换来代码量的大幅下降和可维护性的显著提升。如果你的项目暂时不想引入MyBatis或Spring JdbcTemplate，这种轻量级的自封装方案是一个非常实用的中间选择。