游标刚打开时%FOUND和%NOTFOUND均为NULL，须先FETCH才能安全使用；%NOTFOUND仅反映上一次FETCH结果，非当前状态；预检数据存在性宜用SELECT 1...WHERE ROWNUM=1而非COUNT(*)。
游标刚打开时 %FOUND 和 %NOTFOUND 都是 NULL，不能直接用
刚执行 open 后、还没 fetch，这两个属性既不是 true 也不是 false，而是 null。这时候 if 判断会走 else 分支（因为 null = true 是 false），容易误判“没数据”。
常见错误写法：
OPEN cur;
IF cur%FOUND THEN -- 这里 cur%FOUND 是 NULL，条件不成立
DBMS_OUTPUT.PUT_LINE('有数据');
ELSE
DBMS_OUTPUT.PUT_LINE('没数据'); -- 错！其实还没取呢
END IF;- 必须先
FETCH一次，才能安全读取%FOUND/%NOTFOUND - 如果游标可能为空，推荐用
%NOTFOUND做循环退出条件，而不是靠它判断“初始是否有数据” - 想确认游标是否真有数据，最稳的方式是
FETCH ... INTO后立刻检查%NOTFOUND
%NOTFOUND 在 FETCH 失败后才为 TRUE，且只反映上一次 FETCH 结果
这个属性不是“当前游标状态”，而是“上一次 FETCH 是否成功”的快照。哪怕游标里还有 100 行，只要某次 FETCH 拿不到（比如到了末尾），%NOTFOUND 就变 TRUE，之后再 FETCH 也不会自动重置。
典型陷阱场景：
- 循环中把
FETCH写在EXIT WHEN cur%NOTFOUND后面 → 多取一次，最后一条数据被丢掉 - 重复
FETCH同一个变量，但没重置标志 → 第二次%NOTFOUND还是TRUE，即使游标没关 - 用
%NOTFOUND判断“是否查到某条记录”，却忘了它只管最后一次操作，不管逻辑语义
替代方案：用 SELECT COUNT(*) 预检更直观，但要注意性能和事务一致性
如果业务真需要“提前知道有没有数据”，而不是边取边处理，那硬用游标属性反而绕路。直接查行数更直白：
SELECT COUNT(*) INTO v_cnt FROM employees WHERE dept_id = 10;
但得清楚代价：
-
COUNT(*)可能全表扫描，比带ROWNUM = 1的快速预检慢得多 - 如果后续还要用游标遍历，两次查询之间数据可能被修改（非同一事务或未加锁）
- 简单预检可改用
SELECT 1 FROM ... WHERE ROWNUM = 1，查到就停，开销小
隐式游标（SELECT INTO）的 %FOUND 行为和显式游标不同
隐式游标没 OPEN/CLOSE，执行完 SELECT INTO 立刻就能读 %FOUND —— 这时候它反映的是这次查询是否返回了恰好一行。
注意边界情况：
-
NO_DATA_FOUND异常触发时，SQL%FOUND是FALSE -
TOO_MANY_ROWS触发时，SQL%FOUND是TRUE（因为确实取到数据了，只是太多） - 别混用
SQL%FOUND和自定义游标名的%FOUND，它们互不影响
游标是否含数据，不看名字，看你怎么用；而怎么用，取决于你到底要跳过空集、报错、还是默认兜底 —— 这些决策点比属性本身更关键。
