constant 不必声明在 package body 里，对外暴露的必须放在 package 规范中；私有常量可放 body；命名用 c_前缀、类型宜窄、避免 boolean；跨包引用需 execute 权限且注意编译顺序；运行时配置应改用函数或初始化变量。
constant 必须声明在 package body 里？
不是。pl/sql 中 current（应为 constant）只能在包规范（package specification）或包体（package body）的声明区定义，但**只有放在规范里的 constant 才能被其他包或匿名块直接引用**。放包体里等于私有常量，外部不可见。
常见错误现象：PLS-00201: identifier 'MY_PKG.MY_CONST' must be declared——明明写了，却报未声明，大概率是常量定义在了 PACKAGE BODY 而非 PACKAGE 规范中。
- 对外暴露的常量（如状态码、默认超时值、SQL 模板字符串）必须写在
PACKAGE规范的IS和BEGIN之间 - 仅内部逻辑使用的魔法值（比如某个游标循环里的临时阈值），可放在
PACKAGE BODY声明区，避免污染接口 - 注意：规范中不能执行语句，所以不能用函数调用初始化常量（如
SYSDATE），只能用字面量或编译期可求值表达式（如3600 * 24）
命名和类型怎么选才不容易翻车
PL/SQL 没有枚举或只读变量概念，CONSTANT 全靠命名和类型约束来防误用。起名含糊或类型过大，后续就容易被当成变量赋值、隐式转换出错，或者被其他开发当“临时变量”去改。
典型翻车场景：g_max_retry NUMBER := 3 被当成全局变量反复赋值；status_flag VARCHAR2(1) 存 'Y'/'N'，结果有人塞进 'YES' 导致截断或 ORA-06502。
- 强制前缀：业务常量用
c_（如c_status_active），避免和变量v_、游标cur_混淆 - 类型尽量窄且明确：状态码用
CHAR(1)或PLS_INTEGER，不选NUMBER或VARCHAR2(100) - 字符串常量统一加
_str后缀（如c_sql_select_str），防止和数值型同名冲突 - 避免用
BOOLEAN类型常量——它无法在 SQL 语句中使用（比如WHERE子句里不能写my_pkg.c_is_valid）
跨包引用常量时为什么总遇到权限或编译失败
常量本身不涉及权限，但引用它的包或过程，必须对定义该常量的包有 EXECUTE 权限。否则即使语法没错，也会在运行时报 ORA-00904: invalid identifier 或编译时报 PLS-00302: component 'XXX' must be declared。
更隐蔽的问题是依赖顺序：如果包 A 引用了包 B 的常量，而包 B 尚未成功编译，那么 A 编译会失败，且不会提示“常量不存在”，而是报“标识符无效”。
- 建包时先编译被依赖的包（即定义常量的包），再编译引用它的包
- 给应用用户授予权限时，别只 grant
SELECT，要显式GRANT EXECUTE ON pkg_constants TO app_user - 不要在常量值里拼接对象名（如
c_tab_name CONSTANT VARCHAR2(30) := 'EMPLOYEES'）然后动态 SQL 引用——这会让权限检查绕过静态校验，运行时才爆ORA-00942
想让常量支持运行时值（比如从配置表读）怎么办
CONSTANT 本质是编译期绑定的字面量，没法动态加载。真需要运行时可配的“常量”，得换思路：用包级变量 + 初始化函数模拟，或用视图/函数封装。
但要注意：包级变量不是线程安全的，多个会话可能互相覆盖；而函数调用又有性能开销。别为了“看起来像常量”硬套 CONSTANT。
- 轻量配置（如开关、阈值）：用
FUNCTION get_config_value RETURN NUMBER，内部查缓存表 +RESULT_CACHE提升性能 - 需强一致性（如系统版本号）：在包体初始化块（
BODY的BEGIN ... END;部分）里首次加载到包级变量，并加注释说明“此变量逻辑上为常量，仅初始化一次” - 绝对禁止：在包规范里声明
v_cached_value NUMBER然后到处当常量用——它没有访问控制，也没有初始化保障
真正难的不是定义几个 CURRENT（应为 CONSTANT），是怎么让下一个接手的人一眼看懂哪些值绝不该改、改了会影响哪几条 SQL、以及为什么这个 CHAR(2) 不能扩成 CHAR(3)。这些信息得靠命名、注释、和包结构本身说话，而不是靠口头约定。
