根本原因是目标变量声明长度小于实际字符串字节数：VARCHAR2在编译期确定字节上限，超长即报ORA-06502；中文UTF8占3字节、隐式转换、拼接、%TYPE未重编译、OUT参数未设Size、聚合函数超长及字符集差异均加剧该问题。
根本原因只有一个：目标变量声明的长度小于实际要存入的字符串字节数。不是配置问题，不是环境差异，就是硬性长度不匹配。
变量声明长度小于赋值内容
这是最常见也最直接的触发点。PL/SQL 在编译期就确定了 VARCHAR2 变量的字节上限，运行时一旦赋值超长，立刻抛 ORA-06502。
-
VARCHAR2(10)只能存最多 10 字节（注意：中文在 AL32UTF8 字符集下占 3 字节，所以可能只放得下 3 个汉字） - 隐式转换会放大风险：比如
v_str VARCHAR2(5) := 123456;，数字被转成字符串'123456'（6 字节），直接越界 - 拼接操作容易漏判：
v_str := v_str || 'abc';看似安全，但若初始值已接近上限，拼完就爆
使用 %TYPE 却没同步字段变更
用 table.column%TYPE 声明变量本意是解耦，但如果表结构后续扩容（比如 user_name VARCHAR2(50) 改成 200），而变量没重编译，它仍按旧长度（50）分配缓冲区。
- 现象：存储过程在老数据上正常，一查新插入的长用户名就报错
- 排查重点：查
dba_tab_columns确认字段当前长度，再看变量实际生效长度（可通过DBMS_OUTPUT.PUT_LINE(LENGTH(v_var))辅助验证） - 修复不是改变量，而是重新编译存储过程，让 %TYPE 生效最新定义
OUT 参数长度未显式指定（尤其 .NET 调用场景）
外部程序（如 C#）调用存储过程时，OracleCommand.Parameters 必须为 OUT 参数明确设置 Size。即使 PL/SQL 内部变量是 VARCHAR2(200)，.NET 层不设大小，Oracle 默认按 1 字节分配缓冲区。
- 错误写法：
param.Direction = ParameterDirection.Output;（没设Size） - 正确做法：
param.Size = 200;或更稳妥地，先查表字段长度：SELECT data_length FROM all_tab_columns WHERE table_name='TBL' AND column_name='COL'; - 注意：参数顺序必须和存储过程中声明顺序一致，否则
Size可能错配到其他参数
XMLAGG / LISTAGG 等聚合函数返回超长字符串
这类函数本身不报错，但结果赋给一个短变量时才暴露问题。典型如 LISTAGG(col, ',') WITHIN GROUP (ORDER BY id) 返回 5000 字符，却往 VARCHAR2(4000) 里塞。
- 临时缓解：
SUBSTR(LISTAGG(...), 1, 4000)截断（但会丢数据） - 长期方案：改用
CLOB接收，或重构逻辑避免全量拼接（例如分页聚合、加长度预判） - 注意：
XMLAGG的EXTRACT结果仍是VARCHAR2，不是自动转 CLOB
最容易被忽略的是字符集影响：同一个字符串，在 ZHS16GBK 下是 10 字节，在 AL32UTF8 下可能是 30 字节。别只看“字符数”，一定要用 LENGTHB() 查真实字节数。
