PL/SQL不支持原生可变参数，仅能通过集合类型（如str_array）或分隔符字符串模拟；前者类型安全、推荐使用，后者灵活但易出错且需严格处理空值与截断。
PL/SQL 本身不支持可变参数列表（varargs）
Oracle 原生 PL/SQL 没有类似 Java 的 String... args 或 Python 的 *args 机制。你无法直接声明一个形如 PROCEDURE log_message(p_msg VARCHAR2, p_args ...) 的过程。硬写会报错 PLS-00306: wrong number or types of arguments —— 这是初学者最常卡住的地方。
真正可行的路径只有两条：用集合类型模拟，或改用字符串解析。前者更安全、类型明确；后者灵活但易出错。
用 VARCHAR2 数组接收动态参数（推荐）
定义一个嵌套表类型，作为参数传入，调用方按需填充任意数量的值。这是最接近“动态参数”且保持类型安全的做法。
示例：
CREATE OR REPLACE TYPE str_array AS TABLE OF VARCHAR2(4000);
/
CREATE OR REPLACE PACKAGE log_pkg AS
PROCEDURE log_with_args(p_msg VARCHAR2, p_args str_array DEFAULT str_array());
END;
/
CREATE OR REPLACE PACKAGE BODY log_pkg AS
PROCEDURE log_with_args(p_msg VARCHAR2, p_args str_array) IS
v_full_msg VARCHAR2(32767) := p_msg;
BEGIN
IF p_args.COUNT > 0 THEN
FOR i IN 1..p_args.COUNT LOOP
v_full_msg := v_full_msg || ' | ARG' || i || ': ' || NVL(p_args(i), '(null)');
END LOOP;
END IF;
INSERT INTO app_log(msg, created_at) VALUES (v_full_msg, SYSDATE);
END;
END;
/
调用时可传 0 个、3 个或 10 个参数：
BEGIN
log_pkg.log_with_args('User login', str_array('alice', '192.168.1.5'));
log_pkg.log_with_args('Order processed', str_array('ORD-7782', 'USD', 'shipped'));
END;
- 必须显式构造
str_array()，不能省略括号（否则报PLS-00306） -
DEFAULT str_array()允许省略该参数，但调用时仍要确保类型匹配 - 数组元素上限受
VARCHAR2(4000)限制，超长内容需提前截断或改用CLOB类型
用单个 LONG 或 CLOB 字符串 + 分隔符解析（慎用）
适用于调用方无法控制参数结构的场景（比如从外部系统拼接好再传入），但解析逻辑容易出错，且丧失类型校验。
常见错误现象：ORA-06502: PL/SQL: numeric or value error（分割后某段为空或超长）、ORA-01403: no data found（REGEXP_SUBSTR 索引越界）。
关键点：
- 分隔符必须在业务数据中绝对不出现（推荐用
\x01或|~|，而非逗号或竖线） - 必须检查
REGEXP_SUBSTR返回是否为NULL，不能直接拼接 -
DBMS_LOB操作 CLOB 时注意 chunk 大小，避免隐式转换失败
为什么不用 ANYDATA 或 ANYTYPE？
虽然 Oracle 提供了泛型类型，但它们主要用于数据字典和高级复制，**不适用于常规参数传递**。尝试将 ANYDATA 作为过程参数会导致编译失败或运行时 ORA-22370 错误。
真实约束在于：PL/SQL 的调用栈在编译期就固化了参数签名，任何“运行时决定参数个数”的需求，都必须绕过语法层，落到集合或字符串层面处理。
最容易被忽略的是调用端的兼容性——Java JDBC 调用时，str_array 需注册为 oracle.jdbc.OracleTypes.ARRAY，而字符串解析方式则只需普通 VARCHAR 绑定。选哪种，得先看谁在调你。
