container=all和container=current是ddl语句的作用域修饰符：前者仅在cdb$root中对common user生效，使权限同步至所有已打开pdb；后者为默认行为，限于当前容器，对local user完全有效。
在 oracle 21c 多租户环境下，container=all 和 container=current 不是“配置选项”，而是 grant、revoke、alter user 等 ddl 语句的执行作用域修饰符。它们决定权限或用户属性变更是否跨容器生效——用错就可能授权失败、权限漏发，甚至误改根容器用户。
CONTAINER=ALL 只对 common user 生效，且必须在 CDB$ROOT 中执行
当你用 SYS 或其他具备 COMMON 权限的用户登录到 CDB$ROOT 后，加 CONTAINER=ALL 才会让操作同步到所有已打开的 PDB（包括未来插拔进来的，只要它们没显式关闭该用户）。
- 常见错误：在某个 PDB 内执行
GRANT CONNECT TO app_user CONTAINER=ALL;→ 报错ORA-65048: error encountered when processing the current container，因为 PDB 不支持CONTAINER=ALL - 必须前置条件：被授予权限的用户必须是
common user（用户名以C##或##开头），否则报ORA-65094: invalid local username - 实际效果不是“复制权限”，而是让该 common user 在每个容器中都拥有对应角色/系统权限；但对象权限（如
SELECT ON hr.employees）仍需在各 PDB 单独授予
CONTAINER=CURRENT 是默认行为，但在 PDB 中执行时容易忽略上下文
不写 CONTAINER 子句，或显式写 CONTAINER=CURRENT，表示操作仅作用于当前连接所在的容器。这点看似简单，但极易因连接错容器而出错。
- 典型陷阱：用
sqlplus / as sysdba登录，默认进的是CDB$ROOT；如果本意是给 PDB 中的app_user授CREATE TABLE，却忘了ALTER SESSION SET CONTAINER = mypdb;，结果权限被加到了根容器——而该用户在 PDB 里根本没这个权限 -
CONTAINER=CURRENT对 local user 完全有效（比如在XEPDB1里创建的scott），但对 common user 在 PDB 中执行时，只影响该 PDB 的本地实例，不影响其他 PDB 或 CDB$ROOT - 验证方式：执行完后，在目标 PDB 中查
SESSION_ROLES或DBA_SYS_PRIVS，别只信 CDB 视图
如何安全地批量授权给多个 PDB 中的同名 local user
不能靠 CONTAINER=ALL，因为 local user 不支持它。必须手动切容器，或用脚本循环。
- 最稳妥的手动方式：
ALTER SESSION SET CONTAINER = pdb1;→GRANT CONNECT, CREATE TABLE TO app_user;→ 切到下一个 PDB 重复 - 自动化脚本示例（在 CDB$ROOT 中运行）：
BEGIN FOR r IN (SELECT name FROM v$pdbs WHERE open_mode = 'READ WRITE') LOOP EXECUTE IMMEDIATE 'ALTER SESSION SET CONTAINER = ' || r.name; EXECUTE IMMEDIATE 'GRANT CREATE SESSION TO app_user'; END LOOP; END;注意：该脚本要求app_user已在每个 PDB 中存在，且当前会话有跨容器执行权限（SET CONTAINER权限） - 避免用
DBA_USERS查用户是否存在再创建——PDB 间用户独立，CDB_USERS里的CON_ID字段才是关键定位依据
真正难的不是语法，而是每次执行前必须确认三件事：当前连接在哪（SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL）、目标用户是 common 还是 local、以及你期望的影响范围是否与容器状态匹配——比如一个 PDB 处于 MOUNTED 状态，CONTAINER=ALL 就不会触达它。
