Oracle将包头与包体分离后，DDL锁粒度细化为独立对象：编译包头仅锁包头，编译包体仅锁包体，不阻塞调用方执行或依赖对象访问，显著降低级联锁冲突。
包头和包体分离后，DDL锁作用对象变小了
Oracle对包头（PACKAGE SPECIFICATION）和包体（PACKAGE BODY）分别建模为两个独立的数据库对象。编译包头时只锁定包头本身；编译包体时只锁定包体——不会连带锁住包头，更不会波及调用它的其他过程或表。
对比单独一个存储过程：CREATE OR REPLACE PROCEDURE 语句会整体替换对象，触发对整个过程对象的排他DDL锁，期间任何对该过程的执行、依赖查询、甚至同名对象的元数据访问都可能被阻塞。
- 包头编译失败，不影响已缓存的包体执行（只要没改签名）
- 包体重编译时，只要接口（参数类型/数量/名称）没变，调用方无需重新解析
- 包头里声明的游标、常量、类型等，一旦编译成功，就成为稳定契约；包体实现可反复调试而不破坏外部依赖
编译锁不再跨对象传播，避免级联阻塞
当包体引用了某张表或另一个包，Oracle只在编译包体时对那些被引用对象加共享DDL锁（Share DDL Lock），而不是排他锁。这意味着：其他会话仍可读写该表、可执行那个被引用包——只要不同时去修改它。
而如果把所有逻辑硬塞进一个存储过程中，每次编译都会尝试对每个被引用对象加排他DDL锁（尤其在跨用户调用且未完全限定名时），极易触发LCK_M_X等待链，比如OBJECT: dbid:object_id [[COMPILE]]这类等待资源。
- 包体里调用
pkg_a.func_x，只锁pkg_a的包体（若需重编译），不锁pkg_a包头 - 包头里声明
TYPE t_rec IS RECORD(...)，这个类型定义被多个包体复用，但只在包头编译时锁定一次 - DDL锁粒度从“整个逻辑单元”收窄到“声明契约”和“具体实现”两个正交维度
调试包体时，包头仍可被其他会话安全调用
开发中常遇到：你在PL/SQL Developer里打开包体编辑器并点击“Compile”，此时若包体有语法错误，编译卡住——但只要包头是有效的，其他应用发起的EXEC pkg_name.proc_name仍能走缓存计划正常执行，不会被你这个失败的编译操作拖住。
反观单存储过程：一旦开始CREATE OR REPLACE PROCEDURE且中途出错或挂起，该过程名在整个实例范围内暂时不可用，后续所有调用都会等待DDL锁释放，表现为ORA-04021: timeout occurred while waiting to lock object。
- 包头编译成功后，其接口即固化；包体即使编译失败，也不影响已有调用链路
-
DBA_DDL_LOCKS视图里能看到TYPE = 'PACKAGE'和TYPE = 'PACKAGE BODY'两条独立记录，便于定位到底是哪一层在锁 - 运维批量重编译时，可先跑一遍包头（
ALL_SOURCE里TYPE = 'PACKAGE'），再跑包体，降低锁冲突窗口
包体私有变量和逻辑变更不触发调用方重解析
这是最常被忽略的一点：包体里新增一个私有函数、修改游标查询条件、调整局部变量初始化方式——只要不改变包头声明的任何内容（包括PRAGMA RESTRICT_REFERENCES这类隐式契约），调用方的SQL游标就不会失效，也就不会触发新的编译锁竞争。
而普通存储过程里任何代码行改动，哪怕只是多加一行NULL;，都会导致整个对象版本变更，迫使所有缓存计划失效，下次调用就得抢编译锁重新生成执行计划。
- 包体中
DECLARE v_temp NUMBER := 100;改成v_temp NUMBER := 200;，零影响调用方 - 包头中把
PROCEDURE p(x IN VARCHAR2)改成p(x IN VARCHAR2, y OUT NUMBER)，才会强制调用方重解析 - 这种“接口稳定、实现可变”的特性，本质是把DDL锁的触发边界锚定在契约层，而非代码文本层
