前端无法直连 Oracle REF CURSOR，因其本质是服务端会话绑定的游标句柄，不可跨网络传输或序列化；HTTP 客户端只识别 JSON/XML 响应，不支持 JDBC 的 ResultSet 流式读取，必须由后端物化为结构化数据再返回。
前端无法直接消费 oracle 的 ref cursor，它本质是服务端游标句柄，不是可序列化的数据结构——所有“前端调用 ref cursor”的需求，都必须经由后端 api 做一次结果集物化（即查完、转成 json 或表格数据再返回）。
为什么前端不能直连 REF CURSOR
Oracle 的 SYS_REFCURSOR 是 PL/SQL 运行时对象，生命周期绑定在数据库会话中，不支持跨网络传输。浏览器或移动端 HTTP 请求无法持有这个句柄，更无法像 JDBC 那样调用 rs.next() 流式读取。
- 任何宣称“前端直连 Oracle 游标”的方案，底层必有中间层（如 Node.js/Java 服务）执行
OPEN ... FOR+FETCH ALL+ JSON 序列化 - 试图在 AJAX 中传存储过程名并期望返回游标，只会得到空响应、500 错误或 ORA-01006（bind variable does not exist）
- 前端框架（Vue/React/Angular）的 HTTP 客户端（
fetch、axios）只认 HTTP 状态码和 JSON/XML 响应体，不认识OracleResultSetImpl
常见错误：把后端当透明代理用
有些团队让后端暴露一个通用接口，例如 /api/oracle/execute?proc=get_users，前端传参数、后端反射调用存储过程、再把 ResultSet 直接塞进 ResponseEntity——这看似省事，实则埋雷：
- 未设
fetchSize：百万行结果一次性加载进 JVM 堆内存，触发 Full GC 或 OOM - 未判空
cs.getObject(n)：存储过程中分支未执行OPEN，后端拿到null却直接序列化，前端收到 500 或空数组 - 未关闭资源：
ResultSet、CallableStatement、连接未在finally或 try-with-resources 中释放，连接池迅速耗尽 - 动态 SQL 拼接未过滤：前端传入恶意
where片段，后端不做白名单校验，导致 SQL 注入
正确做法：按业务语义封装，而非按数据库结构暴露
不要让前端决定“我要查哪个游标”，而是定义清晰的业务端点，比如 GET /api/users?dept=10&status=active，后端内部调用对应存储过程，只返回所需字段的 JSON 数组：
- 存储过程仍用
p_result OUT SYS_REFCURSOR，但 Java 层固定用cs.registerOutParameter(2, Types.REF_CURSOR)+(ResultSet) cs.getObject(2) - 对大结果集，显式设置
rs.setFetchSize(200)，并用while (rs.next())流式转 POJO，避免全量加载 - 字段映射不依赖列序：用
rs.getString("USER_NAME")而非rs.getString(1)，防止存储过程调整 SELECT 列顺序导致前端解析失败 - 分页不由前端控制偏移量，而由后端在存储过程中完成（
OFFSET ? ROWS FETCH NEXT ? ROWS ONLY），避免游标跨请求状态丢失
特殊场景：需要前端“分批拉取”怎么办
真有超大数据导出或滚动加载需求，别传游标名，改用唯一任务 ID：
立即学习“前端免费学习笔记（深入）”；
- 第一步：前端 POST
/api/export/submit，后端启动异步任务，执行存储过程、写临时表或文件，返回{ "task_id": "exp_abc123" } - 第二步：前端轮询
/api/export/status?task_id=exp_abc123，后端查临时表状态或文件大小 - 第三步：完成后 GET
/api/export/download?task_id=exp_abc123，后端流式读文件并写入 HTTP 响应体 - 全程不暴露任何游标概念，也不依赖会话保持——HTTP 无状态特性与 Oracle 游标有天然冲突，硬绕只会失控
最易被忽略的一点：REF CURSOR 不是数据，是取数据的“钥匙”。钥匙不能邮寄，只能现场开门、取货、打包、发货。所有试图把钥匙交给前端的操作，本质上都是没关好数据库这扇门。
