SELECT INTO空结果集抛ORA-01403，NVL/COALESCE无效；应捕获NO_DATA_FOUND异常赋默认值，或用MAX()等聚合函数；函数需内部兜底NULL，调用方仍须校验，避免NULL穿透至拼接、计算等关键路径。
用COALESCE或NVL在SELECT INTO前兜底
SELECT INTO遇到空结果集会直接抛ORA-01403，但很多人误以为加个NVL(col, 'default')就能解决——其实没用，异常发生在取值阶段，根本没走到NVL执行。真正有效的做法是在赋值目标上做默认兜底：
- 显式捕获
NO_DATA_FOUND并设默认值：BEGIN SELECT name INTO v_name FROM users WHERE id = p_id; EXCEPTION WHEN NO_DATA_FOUND THEN v_name := '未知用户'; END;
- 若逻辑允许，改用聚合函数绕过异常：
SELECT MAX(name) INTO v_name FROM users WHERE id = p_id;（MAX()无数据时返回NULL，不报错） - 对多行可能场景，优先用游标+
BULK COLLECT，避免SELECT INTO的单行强约束
函数返回值强制非NULL：声明DEFAULT + 调用方校验
Oracle函数本身无法声明NOT NULL返回类型，但可通过约定和实现双重保障：
- 函数体末尾统一用
RETURN COALESCE(v_result, 'N/A');，不依赖调用方处理NULL - 对字符串类函数，定义时就设默认返回值：
v_ret VARCHAR2(100) := 'N/A';，并在所有分支路径确保赋值 - 调用方仍需检查：应用层不能假设“函数有返回就一定非NULL”，尤其当函数内含
SELECT ... INTO且未全覆盖异常时
避免在函数里查可能为空的关联字段
常见陷阱是函数中写SELECT addr.city INTO v_city FROM users u JOIN addresses addr ON u.addr_id = addr.id WHERE u.id = p_id;——一旦addr_id为NULL或关联记录被删，立刻ORA-01403。更稳的做法：
- 把JOIN改成LEFT JOIN + 子查询，并用
COALESCE包住最终值：SELECT COALESCE((SELECT city FROM addresses WHERE id = u.addr_id), '未填写') INTO v_city FROM users u WHERE u.id = p_id;
- 拆分逻辑：先查主表得到
addr_id，再单独判断addr_id IS NOT NULL，只在确认有关联时才查地址表 - 索引要覆盖
addresses.id，否则子查询可能全表扫描
别让NULL穿透到业务关键路径
函数返回NULL本身不是问题，问题在于调用链下游把它当有效值用。比如一个GET_USERNAME(p_id)函数返回NULL，而调用它的报表SQL直接拼接'用户：' || GET_USERNAME(123)，结果整个字段变NULL——因为字符串拼接遇NULL即全NULL。
- 所有涉及拼接、计算、条件判断的上游调用，必须主动用
COALESCE(GET_USERNAME(123), '佚名') - 对金额、状态码等数值型返回，函数内部就该用
NVL(v_amt, 0)或COALESCE(v_amt, 0)，别把转换责任甩给调用方 - 最易忽略的是物化视图刷新场景：函数被MV引用时，若返回NULL，可能触发快速刷新降级为完全刷新，且不报错
