PL/SQL游标泄漏主因是未在异常路径CLOSE显式游标、FOR循环持续占用槽位、包级REF CURSOR长期持有；必须在EXCEPTION中用%ISOPEN判断后CLOSE，且以V$OPEN_CURSOR实时验证是否释放。
PL/SQL显式游标必须配对OPEN/CLOSE，且异常路径不能漏
显式游标一旦OPEN，就占用会话级游标槽位；不CLOSE，该槽位不会释放，哪怕块结束也不会自动清空——Oracle只在最外层匿名块退出时做兜底清理，但不可依赖。常见错误是只在正常路径CLOSE，EXCEPTION里没处理。
- 所有
OPEN语句后，必须确保对应CLOSE被执行，无论是否抛异常 - 推荐写法：在
EXCEPTION块中加IF cursor_name%ISOPEN THEN CLOSE cursor_name; - 避免把
CLOSE放在END;前却没覆盖所有分支（比如RETURN提前退出） - 用
%ISOPEN判断再关，比无条件CLOSE更安全，防止重复关闭报ORA-01001
FOR循环隐式游标也占open_cursors额度，别以为它“自动管理”就没事
FOR c IN (SELECT ...)确实自动OPEN/CLOSE，但它仍会消耗一个游标槽位，并且这个槽位在循环执行期间持续占用。如果嵌套多层、或在包级过程里高频调用，叠加起来照样触达open_cursors上限。
- 每个
FOR循环都会注册一个游标，即使SQL文本完全相同，也不复用已有游标 - 若循环内又调用另一个含
FOR的子过程，游标数线性增长 - 高并发场景下，大量会话同时执行这类循环，比显式游标更容易集体撞限
- 查泄漏时，
V$OPEN_CURSOR里会出现大量sql_text一致但sql_id不同的记录
包级游标变量长期持有是隐蔽泄漏源
把游标声明为包变量（PACKAGE中cur SYS_REFCURSOR），再在过程里OPEN却不CLOSE，会导致游标跨调用生命周期滞留。这种泄漏不会在单次执行中暴露，而是随会话复用缓慢累积。
- 包变量作用域是会话级，只要连接没断，游标就一直开着
-
REF CURSOR赋值给包变量后，原过程里的CLOSE无效，必须在包内显式关 - 连接池环境下，一个物理连接被多个业务请求复用，包变量游标可能被反复
OPEN却从不CLOSE - 排查时需结合
V$SESSION查sid，再连V$OPEN_CURSOR看是否有长时间未更新的游标
验证游标是否真关了：别信日志，要看V$OPEN_CURSOR实时数据
代码里写了CLOSE不等于游标已释放。驱动缓存、异常跳过、或REF CURSOR传递都可能导致CLOSE失效。唯一可靠方式是登录数据库查视图。
- 执行
SELECT sql_id, sql_text FROM v$open_cursor WHERE sid = <your_sid> ORDER BY last_sql_time DESC - 重点看
sql_text是否大量重复、last_sql_time是否长时间没更新 - 同一SQL出现多个不同
sql_id，大概率是FOR循环或未复用PREPARE导致 - 若看到
sql_text含DECLARE或BEGIN，基本是PL/SQL块里游标没关干净
OPEN没配CLOSE。查V$OPEN_CURSOR比读代码更快定位问题。 
