企业官网建设流程全解析

我在最近一个项目里手写了一批 JDBC 代码，期间让 DeepSeek 帮我看了一段“判断 ResultSet 是否为空”的逻辑，结果它洋洋洒洒给了三个方案，其中一个在 MySQL 默认驱动下会直接误判。这倒不是 DeepSeek 的智商问题，而是 JDBC 里ResultSet这个接口天生就没有isEmpty()，也没有size()，很多人第一次写判空都栽在这里。这篇文章就把这个高频小问题讲透：ResultSet 为什么不能像集合一样判空、正确姿势有哪些、不同数据库驱动下的差异、以及我在实际项目里遇到的坑。适合刚接触 JDBC 的初学者，也适合被 AI 建议带偏过的同学，按下面的写法可以直接抄进项目里。

1. 先说结论：ResultSet 不是集合，它是一个“游标”

1.1 为什么 JDBC 不给你一个 isEmpty() 方法

很多人第一次接触 JDBC 时都会下意识去找isEmpty()或者size()，找半天发现ResultSet接口里根本没有这些方法。原因是ResultSet的设计根本不是内存集合，它更像一个“指向结果集当前行”的指针，或者说得直白一点，它像一根水管，数据是一股水流，你只能一根一根地接着喝，不能整根水管抱起来晃一晃问“里面还有没有水”。

我可以用一个更生活的例子解释：ResultSet类似于你在网页上翻页，永远只能看到当前这一页，想看下一页必须点“下一页”按钮，也就是调用next()方法。这个方法每次会做两件事：把游标向下移动一行，然后告诉你移动之后的新位置是否真的有数据。如果返回false，说明已经翻到最后一页之后了，没有更多行了。

所以“判断 ResultSet 是否为空”这个需求，本质上是“判断游标第一次移动时能不能到达一行有效数据”。如果next()第一次调用就返回false，那结果集就是空的；如果返回true，说明至少有第一行。这就是所有判空逻辑的核心原理。

1.2 最常见的错误写法盘点

我在 code review 里见过很多种错误的判空写法，下面这三种出现频率最高，每一种我都踩过或者帮别人排查过。

第一种是把ResultSet和null做比较：

ResultSet rs = stmt.executeQuery(sql); if (rs == null) { // 错误：executeQuery 即使查不到数据，也会返回一个非 null 的 ResultSet 对象 }

这里要特别注意，JDBC 规范中executeQuery()在 SQL 执行失败时抛SQLException，在成功但无数据时返回一个空的 ResultSet 对象，而不是null。所以rs == null这个判断几乎没有成立的机会，写了等于白写。

第二种是用getRow()判断：

if (rs.getRow() == 0) { // 错误：在默认的 TYPE_FORWARD_ONLY 结果集下，getRow() 永远返回 0 }

getRow()返回的是当前游标所在的行号。但 JDBC 默认创建的结果集类型是“只向前滚动”，在这种模式下驱动并不维护行号信息，getRow()恒为 0。我用 MySQL Connector/J 实测过，无论结果集里有没有数据，只要结果集是TYPE_FORWARD_ONLY，rs.getRow()都返回 0。所以用这个判断结果是否为空，在默认配置下会把“有数据”误判成“没有数据”，后果非常严重。

第三种是用first()判断：

if (rs.first()) { // 错误：默认结果集类型下，first() 会抛 SQLException：Operation not allowed for a result set of TYPE_FORWARD_ONLY }

first()是把游标移动到第一行，但这个方法只有创建支持滚动结果集时才能调用，也就是在Statement创建时必须显式指定ResultSet.TYPE_SCROLL_INSENSITIVE或ResultSet.TYPE_SCROLL_SENSITIVE。默认情况下直接调用会抛异常。

现在你应该明白为什么这个题目能做成一篇文章了：一个看起来黑白的“判空”，里面藏了游标机制、结果集类型、驱动实现差异三座大山。

2. ResultSet 判空的标准姿势与边界场景

2.1 标准姿势一：先 next() 再 do-while 处理

这应该是 JDBC 判空最常用、也最不会出错的方式。核心思路是：先调一次next()判断是否有第一行，有就进do-while循环处理第一行，然后再在循环条件里调next()处理后续行。

public List<User> queryUserList(Connection conn, String sql) throws SQLException { List<User> users = new ArrayList<>(); try (Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(sql)) { // 关键点：next() 第一次调用就能判断是否有数据 if (!rs.next()) { System.out.println("结果集为空"); return users; } // do-while 确保不会漏掉第一行 do { User user = new User(); user.setId(rs.getLong("id")); user.setName(rs.getString("name")); users.add(user); } while (rs.next()); return users; } }

这里最容易被新手搞晕的就是 do-while 里的逻辑：为什么先处理一行再进循环？因为第一次if (!rs.next())这个判断已经把游标停在了第一行上，如果这时候你再用while (rs.next())从头开始循环，第一行就会被跳过，最终结果集有 5 行你只拿到 4 行。这是一个非常隐蔽的 bug，不少人就栽在这里。

有人说我用while (rs.next())加一个hasData布尔标记不行吗？完全可以，下面就是第二种姿势。

2.2 标准姿势二：布尔标记法

如果你更喜欢传统的while结构，不想用do-while，那可以用一个布尔变量记录是否进入了循环。这个方法的好处是可读性强，代码结构对新手更友好。

boolean hasData = false; while (rs.next()) { hasData = true; // 处理行数据 } if (!hasData) { System.out.println("结果集为空"); }

但这个方式有个天然限制：它必须在处理完所有行之后才能知道结果集是否为空。如果你的需求是“先判断空，再处理数据”，或者有“空结果集时走 A 分支，非空时走 B 分支”的逻辑，这个方式就有点绕，因为你必须先处理一部分行才能判断。所以我的建议是：需要“空/非空”分支时用第一种if (!rs.next())+do-while；不需要分支、只是单纯遍历数据时用第二种while (rs.next())+hasData。

2.3 边界场景：存储过程返回多个结果集怎么判空

如果 SQL 是存储过程调用，情况会更复杂一些。一个存储过程可能返回多个 ResultSet，也就是一个 Statement 上会连续出现多个结果集。判断“整体是否为空”需要遍历完所有结果集，而不是只看第一个。

CallableStatement cstmt = conn.prepareCall("{call sp_query_user(?)}"); cstmt.setLong(1, userId); boolean hasAny = false; boolean hasMore = cstmt.execute(); while (hasMore) { try (ResultSet rs = cstmt.getResultSet()) { boolean hasRows = false; while (rs.next()) { hasRows = true; hasAny = true; // 处理当前结果集的行 } System.out.println("当前结果集是否有数据: " + hasRows); } hasMore = cstmt.getMoreResults(); } if (!hasAny) { System.out.println("所有结果集均为空"); }

核心要点是execute()和getMoreResults()这两个方法：execute()返回true表示第一个结果是 ResultSet，getMoreResults()用来继续往下探测是否还有更多结果集。很多驱动在存储过程不返回任何结果集时，getMoreResults()会返回true但getResultSet()返回null，这种情况也要单独注意，避免对null的 ResultSet 调用next()。

2.4 边界场景：大字段、分页查询下的游标位置问题

判空之后你还要接着处理数据的话，游标位置就非常重要了。记住一个原则：任何对ResultSet的“探测”操作都会改变游标位置，除非你创建结果集时启用了滚动支持。

在分页查询场景里，很多人先判空再分页，结果发现第一页的数据总是不对。原因就是判空的next()已经把游标移到第一行，后续的分页逻辑再从第一行开始重新查，或者反过来跳过了第一行。最稳妥的做法是：判空和取数放在同一次游标移动中完成，不要“判空一次、取值第二次”。

大字段（比如 CLOB、BLOB）场景下，有些驱动对“是否取到当前行”有额外要求。个别数据库驱动在调用rs.next()后，如果你没有立即读取大字段就移动游标，后面再读那个字段时可能取不到值。所以我的实战建议是：next()移动游标之后，立刻把当前行的所有字段读取到 Java 对象里，不要等到下一个next()再读上一行的字段。

3. 实测：让 DeepSeek 写这段代码，会出现什么情况

3.1 我实际问了一次，它给了三个方案

我自己确实用 DeepSeek 问过一次“JDBC 中 ResultSet 如何判断为空”，它回复的核心内容是：可以用rs.next()判断、可以用rs.getRow()判断、如果结果集支持滚动可以用rs.first()判断。单看答案，语法都对，没有一个是编译错误，但如果直接抄，第一版的getRow()方案在默认配置下就会翻车。

这里要说明，DeepSeek 这类大模型给出的答案是基于它在训练语料里见过的“通用写法”，但 JDBC 是一个 20 多年历史的接口，不同数据库驱动实现差异很大，默认结果集类型在不同数据库上也不完全一致。比如 MySQL 默认是TYPE_FORWARD_ONLY，而某些国产数据库的驱动默认是TYPE_SCROLL_INSENSITIVE，在国产库上getRow()和first()可能没问题，在 MySQL 上就出问题。这就是 AI 辅助编程最大的盲区：它没办法知道你项目里的数据库是什么、驱动是什么、结果集类型是什么。

我不觉得这是 DeepSeek 的问题，JDBC 这种“宽接口、多实现”的生态，哪怕是做了十年 Java 的老手，换一个新数据库驱动也要查文档。所以正确的态度是：让 AI 先给你方向，你自己用本地数据库实测验证，而不是直接 copy。

3.2 我在本地做了一个快速验证

为了验证三种方案在 MySQL 8 驱动下的真实表现，我写了一个小 Demo，建了一张只有 3 行数据的表，然后用三种方式分别判断。

try (Connection conn = DriverManager.getConnection(url, user, password); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from test_user")) { // 方案2验证：getRow() 默认类型下的表现 System.out.println("getRow result: " + rs.getRow()); // 方案3验证：first() 默认类型下的表现 try { System.out.println("first result: " + rs.first()); } catch (SQLException e) { System.out.println("first throws: " + e.getMessage()); } }

实测结果是：表里有 3 行数据，但rs.getRow()返回 0；rs.first()直接抛SQLException，错误信息是Operation not allowed for a result set of TYPE_FORWARD_ONLY。这就是为什么我在这篇文章里反复强调：不要让 AI 直接给你答案，要让 AI 给你“多个思路”，然后你用一个 5 分钟的小 Demo 验证哪个思路在你的数据库驱动上真正可行。

3.3 怎样让 AI 的回答更可靠

如果你想继续用 DeepSeek 辅助这类编码问题，我给你一个我实际试过有效的方法：在提问时把约束条件说清楚，而不是给一个很泛的问题。

比如你可以这样问：我的数据库是 MySQL 8.0，驱动是 mysql-connector-j 8.x，Statement 使用默认的 TYPE_FORWARD_ONLY 创建，请给出在 JDBC 中判断 ResultSet 是否为空且不会改变游标位置的可行方案。加上这些条件之后，AI 给出的答案会收敛很多，它不会再推荐你用getRow()或first()，而是聚焦在next()和蓄意滚动结果集上。

另外一个技巧是二次追问。AI 给出答案后，你可以继续问：“这个方案在调用之后游标位置会怎样变化？是否会影响后续遍历？”这个追问会逼着模型把代码里隐含的状态变化讲清楚，而隐藏状态恰恰是 JDBC 判空最容易出问题的地方。我实测这种追问对提升答案质量非常有效。

4. 实战中容易踩的坑：游标、空值与驱动差异

4.1 游标位置的“一次性糖果”陷阱

ResultSet 游标的一个特点是：一旦移动到下一行，上一行的数据就不能再通过这个 ResultSet 读取了（至少在默认的只进类型下是这样）。所以判空操作本身是一次性的，你用next()判过空之后，游标就已经动了，后续如果再有人调用rs.next()想从头遍历，就会漏掉第一行。

有一次我在一个业务模块里发现了诡异现象：列表接口偶发少一条数据。排查到最后，原因是某个同事在 Service 层调用了自己封装的一个工具类ResultSetUtils.isEmpty(rs)，这个工具类内部调用了rs.next()，而 Service 层拿到返回的 boolean 之后，又单独写了一个while (rs.next())去遍历数据。结果第一行永远被跳过了，只有结果集只有一行时，查出来永远“为空”。这类问题很难在测试阶段暴露，因为很多测试数据不是刻意设计成“结果集第一行极其重要”的。

所以这里有一条硬性经验：判空和取数必须在同一个方法里完成，或者判空之后立即把游标所在的行处理掉。跨方法传递 ResultSet 并各自调用next()是灾难的开始。

4.2 空结果集和有行但列为 null，完全是两回事

有些新手写判断时会把“列值为 null”和“结果集为空”混为一谈，写出这种代码：

rs.next(); if (rs.getObject("name") == null) { // 错误：这只能说明第一行的 name 字段是 null，不能说明结果集没有行 }

这就是把“行是否为空”和“列是否为空”搞混了。结果集为空意味着没有任何行；列值为空意味着有一行，只是某一列的值是null。一个正确的结果集，即使所有列值都是null，它的“存在性”依然是真实的，判空应该用next()而不是取字段值判断。

为了帮团队里的小朋友避开这个问题，我有时候会在代码注释里写得比较狠：“如果你想判断结果集为空，请用 next()，不要用 getObject() == null。前者是有没有米的问题，后者是米里有没有沙的问题，完全不同。”

4.3 一条 SQL 查出来的“空”，也可能是 JDBC 层的资源问题

还有一种情况，你的 SQL 明明在数据库客户端里能查出数据，但 JDBC 里的 ResultSet 却是空的。这种情况往往不是判空逻辑的问题，而是连接或事务层面的坑。

最常见的是事务隔离级别和autocommit的问题。比如你的代码在同一个连接里先执行了一个update，紧接着执行select，而autocommit被关闭了且没有提交事务，某些数据库驱动这时候读到的可能还是更新前的旧快照，或者因为锁等待导致 select 查不到预期数据。这种情况下表现就是“ResultSet 是空的”，但你明明插入了数据。排查方法是在判空分支里打印 SQL 和连接信息，看是不是同一个数据库会话。

还有一种情况是连接被连接池回收，你拿着一个已经失效的Statement去执行查询，驱动静默失败并返回空结果集而不是抛异常。我遇到过某国产数据库驱动在连接失效时，executeQuery()返回空 ResultSet 但不报错，排查了很久才发现是连接空闲超时导致。所以遇到“结果集异常为空”时，不要只盯着判空代码，也看一眼连接池配置和数据库空闲连接回收策略。

4.4 不同数据库驱动的差异速查表

为了避免你被驱动差异坑到，我整理了一个表，基于我实际用过的几个数据库驱动总结，可以作为排查参考。

这个表的结论是：在绝大多数默认配置下，只有rs.next()是万金油。可能有某个少见驱动默认支持滚动，但你没法保证团队里的每一个环境都用同一个驱动，所以统一用next()反而最安全。

5. 可复用的判空工具方法与完整代码

5.1 一个安全的工具方法：判空 + 取数一体化

既然 ResultSet 判空和取数不能割裂，我直接给你一个可以抄进项目的封装。核心思想是：工具类只负责“安全地判断是否存在数据”，并且把游标停在第一行，调用方拿到true后直接用这个ResultSet的第一行继续处理，不需要再调next()。

/** * 判断 ResultSet 是否为空，并将游标停留在第一行(如果有数据的话) * 注意：调用此方法后，游标位置确定：有数据->第一行；无数据->末尾之后 */ public static boolean hasFirstRow(ResultSet rs) throws SQLException { if (rs == null) { return false; } return rs.next(); }

这个方法本身很简单，关键在于使用约定。我一般建议团队这样用：

try (Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(sql)) { if (!JdbcResultSetUtils.hasFirstRow(rs)) { // 空结果集分支：可以返回空列表、返回null、抛出“无数据”业务异常 return Collections.emptyList(); } // 此时游标已经在第一行，直接处理第一行，然后继续 next() do { // 处理行 } while (rs.next()); }

如果你需要在字符串判空时保留原始游标位置（比如调用方不想影响后续逻辑），那就需要创建TYPE_SCROLL_INSENSITIVE结果集，先first()探测，再beforeFirst()复位。但这种方案开销较大，而且要求你创建 Statement 时就指定滚动类型，我并不推荐在生产环境频繁使用，只有特定场景（比如同一个 ResultSet 要传给多个方法分别读取）才值得。

5.2 一个更完整的封装：返回是否为空 + 把数据行转成对象

为了让文章不只是“讲道理”，我再给一个偏实战的封装方法，适合在 DAO 层复用。这个方法把判空和遍历揉在一起，用一个回调接口处理每一行数据，这样调用方完全不用关心游标细节。

@FunctionalInterface public interface RowHandler<T> { T handle(ResultSet rs) throws SQLException; } public <T> List<T> queryAsList(Connection conn, String sql, RowHandler<T> rowHandler) throws SQLException { List<T> result = new ArrayList<>(); try (Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(sql)) { if (!rs.next()) { return result; // 空结果集，返回空列表 } do { result.add(rowHandler.handle(rs)); } while (rs.next()); return result; } }

用法是：

List<User> userList = queryAsList(conn, "select id, name from user where age > 18", rs -> { User user = new User(); user.setId(rs.getLong("id")); user.setName(rs.getString("name")); return user; });

这样判空逻辑收敛在 DAO 公共方法里，业务代码里根本不需要写if (!rs.next())，也就不会犯游标位置重复移动的问题。我现在的项目里就是这么做的，整个团队统一走这个入口，到目前为止没有再出现过“判空后再遍历丢第一行”的 case。

5.3 顺手写个单元测试，把“判空”这件事锁定住

代码写完之后，我强烈建议补一个单元测试，专门验证判空行为。这个测试不需要数据库，如果用 H2 内存库或者 jmockit 这类工具模拟 ResultSet 会更方便。我实际项目里用的是 H2，因为 H2 兼容 MySQL 模式，测 JDBC 逻辑非常方便。

@Test void testResultSetEmpty() throws Exception { // 用 H2 内存库，建一张临时表，插入0行 try (Connection conn = DriverManager.getConnection("jdbc:h2:mem:test;MODE=MySQL"); Statement stmt = conn.createStatement()) { stmt.execute("create table test_empty(id int, name varchar(20))"); try (ResultSet rs = stmt.executeQuery("select * from test_empty")) { assertFalse(JdbcResultSetUtils.hasFirstRow(rs)); } } } @Test void testResultSetNotEmpty() throws Exception { try (Connection conn = DriverManager.getConnection("jdbc:h2:mem:test;MODE=MySQL"); Statement stmt = conn.createStatement()) { stmt.execute("create table test_not_empty(id int, name varchar(20))"); stmt.execute("insert into test_not_empty values (1, 'a')"); try (ResultSet rs = stmt.executeQuery("select * from test_not_empty")) { assertTrue(JdbcResultSetUtils.hasFirstRow(rs)); // 游标停在第一行，可以直接 get 字段 assertEquals(1L, rs.getLong("id")); } } }

单元测试写完之后，我把三种典型错误也顺带验证了一遍：rs == null的判断永远不成立、getRow()在 H2 默认类型下也返回 0、first()在 H2 默认类型下同样抛异常。这让我对“不同驱动实现差异”有了更直观的感知，也让我更坚定了一个原则：JDBC 编程里，凡是依赖驱动行为的代码，都必须用真实环境验证一遍，不能只靠读 API 文档。

6. 排查实录：我遇到过的三个“判空”疑难杂症

6.1 空指针异常：第一次 next() 就抛 SQLException

有一个同事在封装工具类时，把rs.next()放在一个空指针保护后面，然后自信地返回了判断结果。结果线上环境报NullPointerException at JdbcResultSetUtils.hasFirstRow。排查后发现，stmt.executeQuery(sql)本身执行时，如果 SQL 拼错了一个表名，驱动不会返回空的 ResultSet，而是直接抛SQLException，这个异常被上层 catch 吞掉了，返回了一个null给 ResultSet 变量。后续调用rs.next()时自然就空指针了。

这个案例给我的教训是：ResultSet判空之前，先确认异常没有被吞掉。很多人看到SQLException就 catch 后打一行日志继续跑，这种写法的危害比直接抛异常更大，因为它把“SQL 执行失败”伪装成了“查询结果为空”。

6.2 数据凭空丢失：判空与遍历各调了一次 next()

这个案例我前面提到过，就是 Service 层判空、DAO 层遍历的那种。真正让我印象深刻的是，这个 bug 在测试环境没有复现，因为测试表里只有一条数据，被跳过之后看起来就是空列表，测试用例居然还把空列表当成期望值写进去了。后来数据量上来了，每条数据都少一条，线上才炸。

我给的解决方案非常朴素：全团队统一使用 DAO 公共入口方法，业务代码里禁止直接调next()判断后再自己遍历。这个约定立了之后，虽然没有再加什么新技术，但问题彻底消失了。技术方案有时候不需要多高级，需要的是约束足够死。

6.3 结果集明明有数据，工具方法却判空失败

这个案例是最烧脑的。某用户反馈查询结果比预期少，且时好时坏。我看了代码，判空和取数都已经一体化了，理论上没有游标重复移动的问题。后来加日志才发现，这个场景走的是一个事务方法，同一个连接先执行了 update，又执行了 select，连接池把连接切到了另一台数据库实例，而事务没提交。驱动在跨实例查询时，事务内可见性不一致，select 就查不到刚插入的数据。

这个问题的本质已经超出了 ResultSet 判空本身，属于事务和连接管理范畴。我把它写进来是想提醒你：当你的判空逻辑本身没问题，但结果就是意外为空时，排查视角要扩大到连接、事务、隔离级别和数据库负载均衡策略，而不是继续在 ResultSet 上打转。

按我个人经验，这里有一个通用排查顺序：先看 SQL 在数据库客户端执行是否有数据，再看连接是否与之前写操作的连接是同一个，然后看事务是否提交，最后才去怀疑 ResultSet 判空方法本身。按这个顺序排查，我还没有遇到超出一个小时搞不定的问题。

6.4 一次 AI 助手的“翻车”复盘

最后复盘一下文章开头提到的 DeepSeek 案例。当时我拿到的三个方案里，rs.next()方案没问题，getRow()方案在 MySQL 默认驱动下会误判，first()方案要滚动结果集才能用。我直接把实测结果反馈给 DeepSeek，问它“为什么这三句话单独看都对，但实际只有第一个能用”，它的回答总结下来是：JDBC 规范允许驱动实现差异，默认结果集类型是驱动行为，官方文档并未强制要求getRow()在只进结果集里的语义，不同驱动实现不同。

这个回答本身是靠谱的，但这也印证了一点：大模型的训练语料里包含大量不同驱动、不同数据库的杂糅代码，它给你答案时不会自动知道你的运行环境。所以我在文章里给出的经验是：把 AI 当“外脑”，让它帮你罗列可能性，最后的验证一定要落在你自己那把数据库连接上。这不是 DeepSeek 的问题，是任何 AI 编码助手共同的边界所在。

我个人在这个项目里最终的落地做法是：在 DAO 层封装一个queryAsList通用方法，判空逻辑只出现在这一个地方，然后配了两个 H2 单元测试把判空与非判空行为锁定住，其他业务代码一律不允许直接操作 ResultSet 游标。这个方案目前已经在生产环境跑了大半年，没有出现过任何一次“结果集为空”相关的故障。

如果你也在写 JDBC 层代码，希望这篇文章能让你少走一点弯路。记住核心一句话：JDBC 的 ResultSet 没有集合的isEmpty()，它只有游标的next()，判空和取数据要当成一件事来设计，不要拆开。