Package变量和Context均为会话级存储，不跨会话共享；Package变量供PL/SQL内部使用，Context通过SYS_CONTEXT供SQL直接调用，性能更优且支持谓词推入。
Package 全局变量：值在会话内持久，但不跨会话共享
pl/sql package 里的包变量（比如 g_user_id）本质是“会话级静态存储”，只要同一个数据库会话没断，赋过值就一直存在。它不是真正意义上的“全局”，更不是跨用户或跨连接共享的——两个不同连接执行 pkg.set_user(123)，彼此完全看不到对方的值。
常见错误现象：SELECT pkg.g_user_id FROM DUAL 返回 NULL，不是因为没初始化，而是你换了 SQL*Plus 窗口、或用了新连接、或应用里用了连接池导致会话重用后变量被重置；还有的人在匿名块里改了包变量，紧接着开个新查询窗口查，理所当然以为能读到，结果扑空。
实操建议：
- 包变量适合存当前会话上下文信息，比如登录用户、租户 ID、调试开关等，前提是业务逻辑全程走同一个 DB 连接
- 必须显式初始化（在包体的初始化部分），否则首次访问为
NULL，别依赖声明时的默认值（如g_flag BOOLEAN := TRUE在某些 Oracle 版本中未必可靠） - 避免在并行 DML 或自治事务中修改包变量——自治事务会看到父事务的旧快照，改了也白改
Context（上下文）：带命名空间的会话级键值对，支持动态刷新
CONTEXT 是 Oracle 提供的轻量级会话属性机制，通过 DBMS_SESSION.SET_CONTEXT 写入，SYS_CONTEXT 读取。它和包变量一样只存在于当前会话，但关键区别在于：它是“只读视图”驱动的——你不能直接 SELECT 上下文变量，必须用 SYS_CONTEXT('namespace', 'attribute')；而且它的值可以被任何有权限的 PL/SQL 块动态覆盖，包括触发器、策略函数甚至 Java 存储过程。
使用场景：常用于虚拟私有数据库（VPD）、细粒度审计、多租户数据过滤。比如设置 APP_CTX 上下文后，在 WHERE 条件里写 tenant_id = SYS_CONTEXT('APP_CTX', 'current_tenant')，就能自动绑定租户隔离。
实操建议：
- 必须先用
CREATE CONTEXT app_ctx USING ctx_pkg创建上下文，并指定一个 package 作为“设置入口”，否则普通用户无法调用SET_CONTEXT - 上下文值区分大小写，
SYS_CONTEXT('APP_CTX', 'USER_ID')和SYS_CONTEXT('APP_CTX', 'user_id')是两个键 - 不要把敏感信息（如密码、密钥）塞进上下文——它本质是内存字符串，可被同会话其他 PL/SQL 读取，且日志可能泄露
为什么不用 Package 变量替代 Context？
表面看两者都存会话状态，但 Context 的设计目标是“被 SQL 引擎直接消费”。包变量无法在 SQL 表达式中直接引用，你不能写 WHERE status = pkg.g_status；而 SYS_CONTEXT 是 SQL 内置函数，优化器能识别、能做谓词推入、甚至能参与物化视图重写。
性能影响明显：用包变量模拟上下文，往往得靠函数封装（如 pkg.get_status），这会让 SQL 变成非确定性函数调用，导致全表扫描、无法使用索引、统计信息失真；而 SYS_CONTEXT 被 Oracle 视为“稳定函数”，优化器知道它的值在语句执行期间不变。
容易踩的坑：
- 误以为
CREATE CONTEXT后就能随便设值——忘了绑定USING的 package 必须包含合法的SET_CONTEXT调用逻辑 - 在 package 初始化块里调用
DBMS_SESSION.SET_CONTEXT，结果发现 SQL 查询读不到——因为上下文设置必须发生在 SQL 执行前，且 package 初始化不一定触发于你预期的时刻 - 把 Context 当成跨会话通信手段，试图让 A 会话改值、B 会话立刻感知——不可能，Oracle 不提供这种机制
Context 和 Package 变量混用时的典型陷阱
最常见的是“双写不同步”：业务代码既更新 pkg.g_user_id，又调用 DBMS_SESSION.SET_CONTEXT 设置同名上下文。短期看不出问题，但一旦某个模块只读包变量、另一个模块只读上下文，或者中间件重启连接池导致包变量重置而上下文残留，数据就不一致了。
真实案例：某系统用包变量缓存用户角色，同时用 Context 传给 VPD 策略函数。上线后发现部分报表权限异常——查出来是定时任务用自治事务更新了包变量，但没同步更新 Context，VPD 策略仍读旧值。
实操建议：
- 明确分工：SQL 层需要参与过滤/计算的，一律走
SYS_CONTEXT；纯 PL/SQL 内部流程控制用包变量 - 如果必须同步，把设置逻辑收归一个入口函数，内部同时更新两者，禁止分散写入
- 测试时一定要覆盖连接复用场景：用同一连接反复执行设置 → 查询 → 断开 → 新连接查询，验证状态是否符合预期
Context 和 Package 变量都不是跨会话的解决方案，这点容易被忽略。真要共享状态，得上 DBMS_ALERT、UTL_HTTP 调外部服务，或者干脆用数据库表加行锁——但那就完全是另一层权衡了。
