PL/SQL重载函数必须定义在同一PACKAGE中，不能独立存在；参数签名须有实质性差异（不能仅靠返回值），避免隐式转换导致PLS-00307错误；编译期静态解析，无运行时开销。
PL/SQL重载函数必须在同一程序包内定义
oracle不支持在独立过程或函数上直接重载，create or replace function单独执行时无法与同名函数共存。所有重载版本必须封装在同一个package中，由编译器根据参数个数、类型、顺序自动分发调用。
常见错误现象：PLS-00307: too many declarations of 'XXX' match this call，通常是因为参数类型隐式转换导致歧义（比如传入NUMBER却匹配到INTEGER和REAL两个重载），或未使用PACKAGE BODY完整实现。
- 所有重载函数名完全相同，但参数列表必须有可区分的签名（不能仅靠返回值不同）
- 建议统一用
IN参数，避免IN OUT引入调用歧义 - 参数类型优先选基础类型（
VARCHAR2,NUMBER,DATE），慎用%TYPE或记录类型——它们会让签名判断变复杂
参数类型差异要足够明确，避免隐式转换干扰
Oracle按“最精确匹配”原则选择重载版本，但会尝试隐式转换（如CHAR → VARCHAR2、NUMBER → BINARY_INTEGER）。一旦多个版本都能通过转换匹配，就会报PLS-00307。
示例：以下两个函数看似可区分，实则危险：
FUNCTION calc(p_val IN NUMBER) RETURN NUMBER; FUNCTION calc(p_val IN PLS_INTEGER) RETURN NUMBER;
调用calc(42)时，42字面量既可当NUMBER也可当PLS_INTEGER，Oracle无法确定选哪个。
- 改用语义更清晰的类型组合，例如：
VARCHAR2vsDATEvsNUMBER - 必要时用
CAST显式指定类型，如calc(CAST(42 AS PLS_INTEGER)) - 测试时用
DBMS_OUTPUT.PUT_LINE在每个重载体里输出标识，确认实际调用路径
重载函数的返回值类型可以不同，但不能仅靠它区分
Oracle允许重载函数返回不同类型（如一个返回VARCHAR2，另一个返回NUMBER），但**仅返回值不同不足以构成合法重载**——参数签名必须有实质性差异。
典型误用：FUNCTION get_id RETURN NUMBER 和 FUNCTION get_id RETURN VARCHAR2 放在同一包里，编译直接报PLS-00305（name already used by another symbol）。
- 返回值类型差异是副作用，不是重载依据；它只影响调用方如何接收结果
- 若业务逻辑确实需要“同一函数名+不同输入→不同输出”，应确保输入参数类型/个数/顺序至少有一处不可转换的差异
- 注意客户端工具（如SQL*Plus、JDBC）对多态返回值的支持程度，某些驱动可能无法正确绑定动态类型
性能与调试：重载本身无开销，但签名判断发生在编译期
PL/SQL重载解析是静态的，调用时不存在运行时类型检查或分发开销。但过度依赖重载可能增加维护成本——特别是当包内函数超过5个同名版本时，阅读者很难快速定位当前调用的是哪一个。
- 在
PACKAGE SPEC中为每个重载添加简短注释，说明适用场景（如“用于字符串格式化”“用于数值精度计算”） - 避免跨数据类型重载，比如同时支持
VARCHAR2和CLOB——CLOB参数会强制使用临时段，影响性能且不易测试 - 单元测试必须覆盖每种参数组合，尤其边界情况（空字符串、NULL、负数、超长字符）
重载不是语法糖，它是接口设计的一部分；参数签名的可读性，往往比功能复用更重要。
