包头/体分离本身不降低耦合，真正解耦依赖规范中定义稳定接口、体中隐藏实现细节及调用方仅依赖头声明的契约；暴露内部类型、全局变量或未明确定义返回类型均导致强耦合。
oracle pl/sql包的头/体分离本身不直接“降低耦合度”，它提供的是模块化封装能力；真正降低耦合，靠的是在包规范中定义稳定接口、在包体中隐藏实现细节，并配合调用方只依赖包头声明的契约。
为什么包头和包体分离不是解耦的充分条件
很多人误以为只要拆成 PACKAGE 和 PACKAGE BODY 就自动解耦了。实际上，如果包头里暴露太多内部类型、全局变量或过程参数结构，外部代码仍会强依赖具体实现。比如：
- 包头里声明
g_config_table全局嵌套表变量 → 调用方直接读写它，等于把状态逻辑外溢 - 函数返回
RECORD类型但未在包头中明确定义类型 → 调用方必须硬编码字段名，一改就崩 - 包体里调用另一个未封装的私有过程，而该过程又被其他包直接引用 → 包边界形同虚设
真正起作用的三个关键设计点
解耦效果取决于你怎么用分离机制，而不是分离本身：
-
包头只暴露最小必要接口：只声明函数签名、过程原型、公开常量和显式定义的
RECORD或OBJECT类型，不暴露游标变量、中间集合类型、实现细节的异常名 -
所有实现细节锁死在包体内：比如
get_report_columns函数内部用BULK COLLECT查元数据表，但包头只声明RETURN SYS_REFCURSOR—— 调用方不用知道它查的是ALL_TAB_COLUMNS还是缓存表 -
跨包依赖走接口，不走实现：若
PKG_REPORT需要租户上下文，应通过PKG_TENANT.get_tenant_id()调用，而不是直接读PKG_TENANT.g_tenant_id变量 —— 后者一旦改为 session context 方式获取，所有直引用它的包全得改
容易被忽略的耦合陷阱：包级变量与初始化块
包级变量（如 g_tenant_id）和包体中的初始化块（BEGIN ... END;）看似方便，实则埋下隐式耦合：
- 初始化块执行时机不可控：首次调用任意包内对象时触发，但不同会话可能因缓存导致行为不一致
- 全局变量变成状态共享通道：多个业务流程共用同一包实例时，
g_tenant_id被后一个请求覆盖，前一个还在跑就出错 - 测试困难：单元测试无法重置包状态，mock 成本高
更安全的做法是把上下文参数显式传入，或用 DBMS_SESSION.SET_CONTEXT + SYS_CONTEXT 管理，让包彻底无状态。
一个典型解耦示例：报表列定义抽象
假设需要动态生成报表列，不要这样写：
CREATE OR REPLACE PACKAGE PKG_REPORT AS TYPE col_rec IS RECORD (col_name VARCHAR2(100), data_type VARCHAR2(30)); FUNCTION get_columns RETURN col_rec; -- 返回 RECORD，但没定义类型别名 END;
而应这样定义包头：
CREATE OR REPLACE PACKAGE PKG_REPORT AS TYPE t_col_info IS OBJECT (col_name VARCHAR2(100), data_type VARCHAR2(30)); TYPE t_col_list IS TABLE OF t_col_info; FUNCTION get_columns(p_report_id NUMBER) RETURN t_col_list; END;
包体里可自由切换实现方式（查表 / 读配置表 / 解析JSON），只要返回类型一致，上层 SQL 或 PL/SQL 调用完全不受影响 —— 这才是头/体分离真正支撑起的解耦。
