ora-06502是运行时错误，主因是赋值/转换时实际值超变量长度或精度，需定位报错行、检查左右操作数长度（用lengthb()查多字节）、显式控制to_char格式、警惕null导致to_number/to_char崩溃、排查logon触发器及%type未同步等问题。
ORA-06502 是运行时报错，编译通过不代表安全——它只暴露在赋值、转换或隐式操作那一瞬间。
定位具体触发行号和变量
错误堆栈里显示的行号就是关键入口。别跳过它，直接去看那行代码做了什么赋值或函数调用。
- 检查该行左右两侧：左边是声明了长度/精度的变量（如
v_name VARCHAR2(10)），右边是来源（字符串字面量、查询结果、函数返回值、拼接表达式） - 用
DBMS_OUTPUT.PUT_LINE('len=' || LENGTH(<var_name>))</var_name>在出错行前临时加一行，确认实际值长度；对多字节字符集（如 AL32UTF8），改用LENGTHB() - 如果来源是
SELECT INTO，立刻查对应字段在表/视图里的定义：DESC table_name或查USER_TAB_COLUMNS
检查 VARCHAR2 长度是否被隐式突破
“字符串缓冲区太小”这个提示几乎总指向 VARCHAR2 长度超限，但真正原因常藏在隐式行为里。
-
TO_CHAR(date_col)依赖NLS_DATE_FORMAT，默认格式可能生成 20+ 字符，远超你声明的VARCHAR2(10)；必须显式指定格式，例如TO_CHAR(sysdate, 'YYYY-MM-DD') -
||拼接时，哪怕一边是NULL，Oracle 仍会按目标变量长度校验整体结果，v_out VARCHAR2(5) := p_in || '_ext'在p_in为NULL时，等价于'_ext'（4 字符）——看似安全，但若p_in实际是 2 字符，拼出来就 6 字符 - 用
%TYPE声明变量时，别只看当前表结构；上游表字段被ALTER TABLE ... MODIFY加长后，旧过程没重编译，照样崩
警惕 NULL 在数值/字符串转换中的硬崩溃
TO_NUMBER(NULL) 或 TO_CHAR(NULL, 'FM999.00') 不返回 NULL，而是直接抛 ORA-06502——这是最反直觉的一点。
- 所有带格式串的
TO_*()函数都拒绝NULL输入，除非格式串本身允许（极少） - 函数参数为
IN NUMBER时，传入NULL不报错，但后续调用TO_CHAR(p_amt, '999.00')就崩；应在函数开头加IF p_amt IS NULL THEN ...分支 - JDBC 调用中，Java 端
setNull(idx, Types.NUMERIC)到 PL/SQL 层已无类型上下文，无法区分“有意传空”和“未设值”，建议统一用DEFAULT声明参数
排查 LOGON TRIGGER 或系统级触发器
连 sqlplus user/pass 都报 ORA-06502？大概率不是你的代码，而是数据库登录时自动执行的触发器出了问题。
- 查
DBA_TRIGGERS中TRIGGERING_EVENT = 'LOGON '（注意末尾空格），尤其是名字含LOG_DEFERRED、SECURITY、AUDIT的 - 触发器里常见坑：用
VARCHAR2(10)存用户名，但实际用户如sqlreviewer长度 12；用SELECT ... INTO查配置表，但某行字段内容超长 - 临时禁用触发器验证：
ALTER TRIGGER xxx DISABLE;，再试登录；确认后修复触发器里的变量长度或加截断逻辑
真正难的不是看出错行，而是判断那个变量的值到底从哪来、经过了几层转换、中间有没有被隐式截断或扩展——尤其当它来自另一个函数返回值、动态 SQL 结果、或跨 schema 视图时，光看声明毫无意义。
