Oracle默认不支持同名对象多版本并存，版本冲突实为环境间DDL时机差异导致的行为不一致；EBR是唯一原生解决方案，但需满足启用EDITIONS、授CREATE EDITION权限、用户启用EDITIONS三条件，且依赖链、权限、系统包均需适配。
Oracle存储过程版本冲突的本质是对象替换而非并存
直接说结论：oracle默认不支持同一对象名（如pkg_inventory）的多个版本同时存在并按需调用——你执行create or replace procedure，旧版本就没了。所谓“版本冲突”，其实是开发、测试、生产环境间因ddl顺序/时机不同，导致调用方看到的签名或行为不一致，进而引发pls-00302、ora-06550或运行时逻辑错乱。edition-based redefinition（ebr）是oracle 11gr2起提供的唯一原生机制，允许同一对象名在不同edition下共存，但它的启用不是加个开关就行，而是整套权限与会话模型的切换。
启用EBR前必须满足三个硬性条件
缺一不可，否则CREATE EDITION会报ORA-38802或ORA-38804：
- 数据库必须启用
ENABLE EDITIONS：需DBA执行ALTER DATABASE EDITIONS ENABLE;（仅一次，重启生效） - 目标用户必须被显式授予
CREATE EDITION权限（普通用户默认无）：GRANT CREATE EDITION TO your_user; - 该用户schema下所有要版本化的对象（包、过程、函数），必须先用
ALTER USER your_user ENABLE EDITIONS;标记为“可版本化”——注意：这一步会隐式重建该用户的USER_OBJECTS视图，已有对象不会自动迁移，需后续手动编译进edition
典型EBR工作流：从开发到灰度上线
不是“写两个版本扔进去”，而是通过edition分层控制可见性：
- 先创建基础edition：
CREATE EDITION dev_edition;（初始所有对象都在ORA$BASE） - 让开发版对象进入新edition：
ALTER PACKAGE pkg_inventory COMPILE EDITIONABLE EDITION dev_edition;（此时pkg_inventory在dev_edition下有新版，在ORA$BASE下仍是旧版） - 关键：会话必须显式切换edition才能看到新版：
ALTER SESSION SET EDITION = dev_edition;——未执行此句的会话，哪怕执行了CALL pkg_inventory.do_calc()，调用的仍是ORA$BASE下的旧版 - 灰度验证时，只给部分应用连接串追加
EDITION=dev_edition参数（JDBC需用oracle.jdbc.editionName属性），其余仍走ORA$BASE，零停机切换
EBR最常被忽略的坑：依赖链断裂与权限继承
EBR不自动复制权限，也不保证跨edition调用安全：
- 若
pkg_inventory（新版）里调用了func_util（旧版在ORA$BASE），且func_util未在dev_edition中重新编译，则运行时报PLS-00302：“identifier 'FUNC_UTIL' must be declared”——必须把整个依赖链的所有对象都编译进同一edition - 对象在
dev_edition中编译后，其EXECUTE权限不会自动继承给原授权用户；需DBA显式执行GRANT EXECUTE ON pkg_inventory TO app_user EDITIONABLE;（注意末尾EDITIONABLE关键字） -
DBMS_LOCK或UTL_HTTP等系统包不支持edition切换，它们始终从ORA$BASE解析——若你的新版过程依赖这些包的特定行为，得确认ORA$BASE中的版本是否兼容
CREATE OR REPLACE过。没切edition的运维脚本、忘了配EDITION参数的中间件、或者直接用SQL*Plus连库的DBA，都可能无意中绕过你的灰度策略。
