包规范是接口契约，仅声明函数、过程、参数等而不含实现；修改规范会导致所有依赖对象失效，引发ORA-04068等错误；包体升级可热替换，安全无感；真正需改规范时应优先采用新增、默认值或重载等向后兼容方式。
包规范（PACKAGE SPEC）本质是接口契约
Oracle 包规范定义的是对外暴露的函数名、过程名、参数类型、返回类型、变量声明和游标声明，它不包含任何实现逻辑。这就像 Java 的 interface 或 C++ 的头文件（.h），只承诺“能做什么”，不承诺“怎么做”。只要新增功能不改变已有签名，就不需要动规范。
修改包规范会触发所有依赖对象失效
一旦你改动了 CREATE OR REPLACE PACKAGE 中的规范部分（比如删掉一个 PROCEDURE foo，或把 IN NUMBER 改成 IN VARCHAR2），Oracle 会强制将所有调用过该包的对象（视图、其他包、函数、触发器等）标记为 INVALID。下次执行时需重新编译，可能引发运行时错误或延迟。
- 常见现象：应用突然报错
ORA-04068: existing state of packages has been discarded或ORA-04061: existing state of package "XXX" has been invalidated - 影响范围远超预期：哪怕只改了一个参数名，所有引用该包的 PL/SQL 块都得重编译
- 生产环境尤其危险：自动重编译可能失败，导致服务中断
包体（PACKAGE BODY）升级是安全的热替换
包体只含实现逻辑，Oracle 允许在不中断服务的前提下用 CREATE OR REPLACE PACKAGE BODY 替换它。只要规范没变，已加载进共享池的调用上下文不受影响，正在执行的会话继续跑旧逻辑，新会话自动用新逻辑。
- 典型场景：修复一个
FUNCTION calculate_tax的计算 bug，只需重编译包体 - 性能无感知：替换过程毫秒级，不锁表、不阻塞查询
- 可灰度验证：先在测试库验证新包体，再上线，风险可控
真正需要改规范的少数情况
不是不能改，而是要极度谨慎。只有当业务语义必须扩展接口能力时才动规范，且优先用向后兼容方式：
- 新增函数或过程（不破坏原有调用）
- 增加带默认值的
IN参数（如PROCEDURE log_msg(p_msg VARCHAR2, p_level NUMBER DEFAULT 1)） - 新增重载版本（overload），而非修改原签名
- 绝对避免：删函数、改参数顺序、改非默认参数类型、改返回类型
复杂点在于：很多人误以为“加个日志参数”是小改动，但若没设默认值，所有调用方代码就得同步改——这才是规范变更最常被忽略的连锁成本。
