Oracle PL/SQL包全局变量生命周期绑定会话而非调用，导致跨调用状态残留；修复需按语义显式初始化或提供reset接口，并警惕AUTONOMOUS_TRANSACTION不隔离包变量。
包全局变量在会话内持续存在，不是每次调用都重置
Oracle PL/SQL 包的全局变量（即包体或包头中声明的 g_counter、g_list 这类变量）生命周期绑定到**会话（session）**，而非过程调用。这意味着：第一次调用 pkg_calc.calc_total() 后，g_sum := 100；第二次再调用，g_sum 仍为 100，除非显式清零。很多“计算结果越跑越大”“同一输入返回不同值”的问题，根源就在这儿。
常见错误现象包括：
- 批量处理时，第 2 批数据的结果 = 第 1 批 + 第 2 批（实际应只算第 2 批）
- Web 应用复用连接池中的会话，用户 A 的计算污染了用户 B 的结果
- UTL_HTTP 或 DBMS_SCHEDULER 调用后，包变量残留导致后续逻辑错乱
怎么确认是不是包变量没清空？
最直接的办法是加诊断输出，但别用 DBMS_OUTPUT.PUT_LINE（它可能被关闭或缓冲）。改用写表或查 V$SESSION 关联的会话级状态：
- 在包里加一个调试函数，比如
pkg_calc.show_state，里面查SELECT SYS_CONTEXT('USERENV', 'SID') FROM DUAL并把当前变量值 INSERT 到日志表 - 手动模拟复现：开两个 SQL*Plus 窗口，分别连同一用户，执行两次相同调用，然后查日志表对比 SID 和变量值是否跨调用延续
- 检查包头是否用了
PRAGMA SERIALLY_REUSABLE—— 如果用了，变量本该自动重置，但该 pragma 仅对包体有效，且不支持游标变量和某些复杂类型，容易误判
修复方案要分场景选，不能一刀切
不是所有包变量都要改成局部变量。关键看语义：
- 如果变量只是临时缓存中间结果（如累加器、临时列表），**必须在入口过程开头显式初始化**：
g_sum := 0;或g_list.DELETE; - 如果变量是真正需要跨调用保持的状态（如会话级计数器、权限上下文），那就得明确文档化，并在业务逻辑结束点提供
reset_state接口，由调用方控制生命周期 - 避免在包里用
EXCEPTION WHEN OTHERS THEN NULL吞掉异常——万一初始化失败（比如表空间满导致日志插入失败），后续变量就处于未知状态，错误更难定位 - 对批量作业，优先考虑把状态移到过程参数或临时表中，而不是依赖包变量；这样还能天然支持并行（
DBMS_PARALLEL_EXECUTE）
最容易被忽略的点：AUTONOMOUS_TRANSACTION 会隔离包变量吗？
不会。自治事务只隔离事务上下文（COMMIT/ROLLBACK 不影响主事务），但**不隔离包变量作用域**。一个包里既有主逻辑又有自治日志记录过程，g_error_count 在自治过程中自增，主过程下次读仍是新值。这点在写错误重试逻辑时特别危险——你以为日志写完了变量就清了，其实没有。
所以，只要包里有自治事务，所有共享变量都必须加上“是否在自治上下文中”的判断逻辑，或者干脆拆成两个独立包，物理隔离状态。
