优先选 SYS_REFCURSOR 是因为它自 Oracle 9i 起内置、弱类型、无需预定义、可接任意查询结构，而自定义 REF CURSOR 强类型限制多、维护成本高、外部程序不感知且易引发 ORA-01008 等运行时错误。
直接用 SYS_REFCURSOR，别自己定义类型——除非你真需要强类型约束。
为什么优先选 SYS_REFCURSOR 而不是自定义 REF CURSOR 类型？
Oracle 9i 起就内置了 SYS_REFCURSOR，它是一个弱类型游标，能接任意结构的查询结果。你自己在包里定义 TYPE mycur IS REF CURSOR 属于强类型，必须显式声明返回列结构（比如 RETURN emp%ROWTYPE），但实际业务中很少需要这种限制：
- 强类型游标无法接收
SELECT a, b FROM t1 UNION SELECT x, y FROM t2这类列名/类型不完全一致的查询 - Java、C#、Python 等外部程序根本不关心游标是否强类型，只认
REF CURSOR语义 - 包头多一层类型定义，徒增维护成本；出错时堆栈里还多一个自定义类型名，排查更绕
OPEN ... FOR 必须在过程体里执行，不能延迟或条件跳过
REF CURSOR 是“打开即绑定结果集”的机制，OPEN p_cursor FOR ... 这行代码一执行，数据库就分配内存、生成执行计划、开始读取数据（哪怕还没被客户端 fetch）。常见错误包括：
- 在
IF分支里只对部分路径调用OPEN，另一些路径没写 —— 调用端会报ORA-01008: not all variables bound - 试图把
OPEN放到函数返回值里（如RETURN p_cursor）—— PL/SQL 不支持游标作为函数返回值直接传递，必须用OUT参数 - 在
EXCEPTION块里补OPEN p_cursor FOR SELECT * FROM DUAL WHERE 1=0占位 —— 可行但丑陋；更干净的做法是确保所有分支都有OPEN，哪怕查空集
PL/SQL 测试时怎么看到结果？别信“点击 Cursor 小按钮”
SQL Developer 或 PL/SQL Developer 的图形化“测试”功能容易误导人：它背后其实是帮你隐式声明了一个 :cur_var 变量并调用 PRINT，但这个行为不可控、不透明，且无法模拟真实 JDBC/C# 场景下的连接生命周期问题：
- 必须手动加
SET SERVEROUTPUT ON才能看到DBMS_OUTPUT.PUT_LINE输出，但这和游标无关 - 真正验证游标内容，应该用匿名块显式声明变量并
FETCH，例如：
BEGIN
DECLARE
l_cur SYS_REFCURSOR;
l_name VARCHAR2(100);
l_id NUMBER;
BEGIN
p_test(l_cur); -- 假设这是你的过程
LOOP
FETCH l_cur INTO l_id, l_name;
EXIT WHEN l_cur%NOTFOUND;
DBMS_OUTPUT.PUT_LINE(l_id || ': ' || l_name);
END LOOP;
CLOSE l_cur;
END;
END;这样你才能确认字段顺序、空值处理、异常中断等细节是否符合预期。
Java/C# 调用时最常漏掉的三件事
REF CURSOR 的本质是服务端打开的一个指针，它的生命周期完全依赖数据库连接。外部程序稍不注意就会在读取中途断连或复用连接：
- Java 里没调用
cstmt.registerOutParameter(1, OracleTypes.CURSOR)—— 会得到java.sql.SQLException: Invalid column type - C# 中
OracleParameter没设OracleDbType.RefCursor，而是用了默认类型 —— 结果集为空，且无明确报错 - Spring
@Transactional方法里调用后，事务提交导致连接归还池子，但ResultSet.next()还没跑完 —— 下一秒就抛ORA-01001: invalid cursor
真正安全的做法是：拿到 ResultSet 后，在同一连接上同步读完、关闭，不要跨方法、跨线程、跨事务边界持有游标。
