包变量会导致会话污染，因其绑定于数据库会话生命周期而非连接，连接池复用时残留旧值引发租户id错乱、权限误开等问题；需显式初始化与重置，优先使用context替代。
包变量为什么会导致会话污染
包变量（如 g_user_id）本质是会话级静态存储，不是跨连接共享的“全局”变量，而是绑定在当前数据库会话生命周期内。一旦应用使用连接池（如 Tomcat JDBC），旧会话被复用时，前一个用户留下的包变量值仍残留，新业务线程就会读到不属于自己的数据——比如租户 ID 错乱、权限开关误开，线上故障难复现。
典型现象包括：SELECT pkg.g_user_id FROM DUAL 返回上一个用户的值；调用存储过程后 ORA-04068 报错（包状态丢失）；多线程并发下结果不可预测。
- 包变量不随连接关闭自动清空，只随会话终止或显式重置才消失
- 自治事务中修改包变量无效——它看到的是父事务快照，改了也白改
- Oracle 10g+ 中，包内声明的常量（
g_flag CONSTANT BOOLEAN := TRUE）也会触发状态化，导致ORA-04068
如何安全初始化和重置包变量
不能依赖声明时的默认值（如 NUMBER := 0），某些 Oracle 版本对布尔型常量初始化不可靠；必须在包体初始化部分（BEGIN ... END; 块）显式赋值，且每次会话首次访问前确保已执行。
- 初始化代码必须放在包体末尾的匿名初始化块中，例如：
BEGIN<br> g_user_id := NULL;<br> g_debug_mode := FALSE;<br>END;
- 提供显式重置过程（如
pkg.reset_context），由应用在关键入口（如登录后、租户切换时）主动调用 - 避免在触发器或策略函数里隐式修改包变量——它们可能在你不知情时污染状态
Context 比 Package 变量更适合 SQL 层消费
如果你需要让 SQL 查询直接读取会话上下文（比如 WHERE tenant_id = SYS_CONTEXT('APP_CTX', 'current_tenant')），别用包变量硬顶。Context 是 Oracle 专为 SQL 引擎设计的轻量级机制，支持谓词推入，性能更好，且值可被任意 PL/SQL 动态刷新。
- 必须先创建上下文：
CREATE CONTEXT app_ctx USING ctx_pkg，并指定一个 package 作为设置入口 -
SYS_CONTEXT的键名区分大小写：SYS_CONTEXT('APP_CTX', 'USER_ID')≠SYS_CONTEXT('APP_CTX', 'user_id') - Context 不允许存敏感信息——同会话内任何 PL/SQL 都能读取，日志也可能泄露内存字符串
什么情况下真该用包变量
仅当满足三个条件：业务逻辑全程走同一个 DB 连接、无连接池复用、无需 SQL 层直接引用。典型适用场景是调试开关、临时缓存计算中间值、单次事务内状态传递。
- 优先通过参数传值替代包变量——过程间通信尽量用
IN/OUT参数，而非共享变量 - 若必须用，封装
get_g_user_id和set_g_user_id函数，禁止直接赋值 - 上线前检查
USER_OBJECT_SIZE视图中包的PARSED_SIZE，超过 5000 行就该拆分，长包容易加剧状态管理复杂度
