可行，但仅限于同一包的声明部分，且参数数量、类型或顺序须有实质差异；Oracle 12c起支持返回类型区分，11g及以前仅依赖参数列表。
PL/SQL 中同名 Procedure 重载是否可行？
可行，但仅限于同一个包（package）的声明部分（spec），且必须满足参数数量、类型或顺序有实质差异。不是所有 oracle 版本都默认支持——oracle 12c 及以后版本才完整支持重载（包括返回类型不同也可区分），11g 及更早版本只认参数列表，不看返回类型。
常见错误现象：PLS-00307: too many declarations of 'XXX' match this call，说明调用时编译器无法唯一确定该调哪个重载版本，通常因为参数隐式转换导致歧义。
- 重载只能在
PACKAGE规范中声明，不能在包体（body）里单独加一个同名 procedure 就算重载 - 参数类型必须是“不可隐式转换为彼此”的类型，比如
VARCHAR2和NUMBER可以，但CHAR和VARCHAR2在多数上下文会被视为等价，容易触发歧义 - 带默认值的参数要小心：如果两个重载版本都有默认值，且调用时省略参数，编译器可能无法分辨
怎么写才能让重载真正生效？
关键在 package spec 中显式声明多个同名 procedure，参数签名必须可区分；包体中对应实现也要一一匹配，名字相同、参数个数和类型顺序完全一致。
示例（Oracle 19c）：
CREATE OR REPLACE PACKAGE demo_pkg AS PROCEDURE log_msg(p_text IN VARCHAR2); PROCEDURE log_msg(p_id IN NUMBER, p_text IN VARCHAR2); PROCEDURE log_msg(p_ts IN TIMESTAMP, p_text IN VARCHAR2); END demo_pkg;
对应包体里必须有三个 log_msg 实现，不能少，也不能参数类型写错（比如把 TIMESTAMP 写成 DATE）。
- 每个重载版本的参数名可以不同，但类型+顺序必须构成唯一签名
- 不能仅靠
IN/OUT模式不同来重载（如一个IN，一个OUT）——Oracle 不认这个区别 - 如果用了
CHAR、LONG或用户自定义对象类型，要确认它们在重载上下文中是否参与类型匹配（LONG基本不参与，且已被弃用）
调用时为什么总是报 PLS-00307？
不是代码写错了，而是你传的实参让 Oracle 找到了多个“看起来都能接住”的重载版本。典型场景：传了 NULL、字面量数字或字符串、或者用了函数返回值但类型不明确。
比如：demo_pkg.log_msg(NULL); —— NULL 没有类型，Oracle 会尝试匹配所有接受可为空标量类型的重载，结果发现 VARCHAR2、NUMBER、TIMESTAMP 版本全都能隐式转，就报错。
- 解决办法：显式转换，比如
demo_pkg.log_msg(CAST(NULL AS VARCHAR2)); - 避免用字面量
123调用，而应写demo_pkg.log_msg(TO_NUMBER('123'), 'xxx');明确类型 - 如果调用方是另一个 PL/SQL 块，确保变量已正确定义类型（
v_id NUMBER;而非v_id PLS_INTEGER;，除非你真想用后者）
重载对性能和迁移有什么隐性影响？
运行时无额外开销——重载解析发生在编译期，调用时跟普通 procedure 一样快。但维护成本会上升：别人读代码时，得来回翻 package spec 才知道当前调的是哪个版本；工具（如 IDE、静态检查器）也可能识别不准。
更麻烦的是迁移：从 11g 升级到 19c 后，原来因版本限制没启用的重载，一旦打开，可能让旧脚本突然编译失败（比如之前能编译的模糊调用，现在被严格拒绝）。
- 上线前务必用
ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL';检查潜在重载冲突 - 不要在 public 包里随意加重载，尤其当外部系统直接调用时——它们可能依赖固定签名
- 如果只是想“复用名字”，比方说统一入口分发逻辑，考虑用单个 procedure +
CASE判断参数类型，反而更可控
