DBMS_OUTPUT.PUT_LINE触发ORU-10027是因缓冲区满而非拼接错误，需在BEGIN首行调用DBMS_OUTPUT.ENABLE；VARCHAR2拼接超长抛ORA-06502，应改用CLOB或分段输出；LISTAGG超限须转XMLAGG+XMLCAST为CLOB；Java/.NET调用需显式指定参数长度。
DBMS_OUTPUT.PUT_LINE 触发 ORU-10027 错误
这不是拼接逻辑错了，而是输出通道被堵了。oracle 默认 dbms_output 缓冲区只有 10000 字节，put_line 只要累计超这个数就报 oru-10027: buffer overflow, limit of 10000 bytes，和你拼的字符串本身是否超长无关。
关键动作必须放在 BEGIN 块第一行：
-
DBMS_OUTPUT.ENABLE(buffer_size => NULL)—— 彻底取消限制（推荐调试用） -
DBMS_OUTPUT.ENABLE(10000000)—— 设为 10MB（生产环境更可控）
注意：ENABLE 必须在任何 PUT_LINE 之前执行；客户端还要配 SET SERVEROUTPUT ON SIZE UNLIMITED（SQL*Plus/SQLcl）或勾选 “Enable DBMS Output”（SQL Developer）。
VARCHAR2 拼接中途炸掉：ORA-06502
当用 VARCHAR2(4000) 变量循环拼接日志、SQL 片段或条件串时，一旦中间结果超过 4000 字节（不是字符！UTF8 下一个 emoji 就占 4 字节），立刻抛 ORA-06502: character string buffer too small。
别只盯着“加长度”，先判断场景：
- 纯日志拼接 → 改用
CLOB+DBMS_LOB.WRITEAPPEND，避免隐式转换 - 动态 SQL 构建 → 直接用
CLOB接收LISTAGG/XMLAGG结果，再传给EXECUTE IMMEDIATE - 临时调试输出 → 把大拼接拆成多条
PUT_LINE，每条控制在 2000 字节内
CONCAT 或 || 不会自动扩容，它只认左边变量声明长度。
LISTAGG / XMLAGG 拼接结果超 4000 字符
LISTAGG 返回类型是 VARCHAR2，硬顶 4000 字节上限。哪怕源数据每行才 10 字符，拼 500 行也大概率溢出。
绕过方式不是调大变量，而是换返回载体：
- 用
XMLAGG+XMLCAST转CLOB：XMLCAST(XMLAGG(XMLELEMENT(E, col || ',')).EXTRACT('//text()') AS CLOB) - Oracle 12c+ 可加
ON OVERFLOW TRUNCATE（但会丢数据，慎用） - 真要截断，用
SUBSTR(..., 1, 4000)显式控制，别依赖数据库静默截断
注意：XMLAGG 结果默认带 XML 标签，EXTRACT('//text()') 才能干净取值。
Java/.NET 调用端同步踩坑
存储过程里变量声明是 VARCHAR2(4000)，但 Java 侧 registerOutParameter(1, Types.VARCHAR) 没设长度，JDBC 驱动可能按默认 128 字节分配缓冲——还没进 PL/SQL 就被截断，错误还报在调用层。
必须两端对齐：
- Java：
cs.registerOutParameter(1, Types.VARCHAR, 4000)（第三个参数不能省） - .NET：
parameter.Size = 4000（OracleParameter） - 若过程改用
CLOB输出，Java 必须用setCharacterStream或registerOutParameter(..., Types.CLOB)
最隐蔽的坑：同一字段在不同存储过程中被声明为 VARCHAR2(100) 和 VARCHAR2(200)，调用方却复用旧参数配置——这种不一致不会编译报错，只会在某次数据变长时突然崩。
