no_data_found仅在select into无返回行时触发，fetch等不引发；需用嵌套begin-end局部捕获并设默认值；禁用max()规避，避免性能损耗与语义错误；函数内该异常被静默转为null，过程则报错。
NO_DATA_FOUND只在SELECT INTO时触发，别在其他地方乱抓
这个异常不是“查不到数据就抛”，它只在 SELECT ... INTO 语句没返回任何行时由 PL/SQL 引擎主动抛出。用 FETCH、BULK COLLECT、普通 SQL 查询（如直接在 SQL*Plus 里执行）都不会触发它。很多人在游标循环里写 WHEN NO_DATA_FOUND THEN ...，结果永远进不去——因为 %NOTFOUND 是游标属性，不是异常。
嵌套BEGIN-END块是安全处理的关键结构
如果你在 SELECT INTO 后面还有必须执行的逻辑（比如日志输出、变量默认赋值、后续计算），不能把整个过程包在一个大 EXCEPTION 里，否则一出异常就跳走了。正确做法是局部隔离：
- 用独立的
BEGIN ... EXCEPTION ... END;包住那条SELECT INTO - 在
EXCEPTION分支里给目标变量设默认值（如v_name := 'UNKNOWN';） - 外层代码照常运行，不会中断
示例：
BEGIN
BEGIN
SELECT ename INTO v_name FROM emp WHERE empno = 9999;
EXCEPTION WHEN NO_DATA_FOUND THEN
v_name := 'UNKNOWN';
END;
DBMS_OUTPUT.PUT_LINE('员工名: ' || v_name); -- 这行总能执行
END;
别用MAX()硬绕过，小心性能和语义错位
有人把 SELECT col INTO v_col 改成 SELECT MAX(col) INTO v_col 来避免异常，这确实不抛 NO_DATA_FOUND，但代价明显：
-
MAX()会强制全表扫描或索引全扫，哪怕原查询条件能走唯一索引快速定位 - 如果业务逻辑要求“必须有且仅有一行匹配”，用
MAX()会掩盖TOO_MANY_ROWS异常，导致数据错误被静默吞掉 - 返回
NULL和“未找到”语义不同：前者可能是合法空值，后者是业务缺失
函数内NO_DATA_FOUND会被SQL引擎静默吞掉，过程不会
这是最容易忽略的兼容性差异。当你在 SQL 语句中调用一个含 SELECT INTO 的函数（如 SELECT fn_test('x') FROM dual），若该函数内部触发 NO_DATA_FOUND，Oracle 会直接返回 NULL，不报错也不传播异常；但同样的代码放在存储过程中执行，就会立刻中断并报 ORA-01403。所以函数里做 SELECT INTO 必须自带异常处理，不能依赖外层兜底。
