execute immediate 不支持对表名、列名等标识符使用绑定变量，因解析阶段需确定对象结构而绑定值仅执行时才代入；必须通过 dbms_assert.simple_sql_name 等校验后拼接，且 ddl 自动提交不可回滚，跨环境需显式指定 schema 并校验权限。
EXECUTE IMMEDIATE 不能对表名、列名等标识符使用绑定变量，这是硬性限制，不是写法问题 —— 直接用 :table_name 肯定报 ORA-00184 或 ORA-00900。
为什么表名不能用绑定变量？
Oracle 在 SQL 解析阶段就必须确定对象结构（比如表是否存在、字段类型是否匹配），而绑定变量的值只在执行时才代入，解析器无法据此做元数据校验。所以 DDL 和 DML 中所有对象名（CREATE TABLE :t、SELECT * FROM :tab）一律不支持绑定。
动态拼接表名必须做白名单校验
直接字符串拼接 v_sql := 'SELECT * FROM ' || v_tabname 看似简单，但若 v_tabname 来自用户输入或外部参数，极易引发 SQL 注入 —— 比如传入 't1 UNION SELECT password FROM users--' 就可能拖库。
- 优先用
DBMS_ASSERT.SIMPLE_SQL_NAME校验：它只允许字母、数字、下划线、井号、美元符，且长度 ≤ 30，能拦掉绝大多数恶意输入 - 若业务允许更宽松的命名（如含连字符），需自行实现白名单正则，例如
REGEXP_LIKE(v_tabname, '^[a-zA-Z][a-zA-Z0-9_\-#\$]{0,29}$') - 绝对不要用
REPLACE或TRANSLATE做“过滤”，它们无法覆盖嵌套注入（如't1 --'后加换行）
DDL 执行后自动提交，没法回滚
用 EXECUTE IMMEDIATE 执行 CREATE、DROP 等 DDL，事务会立即提交，哪怕外面包着 BEGIN...EXCEPTION...END 也无效。这意味着：
- 如果后续步骤失败，前面建的表删不掉，状态不一致
- 想回滚，得改用
DBMS_SQL包（但性能差、代码冗长，仅限极特殊场景） - 更稳妥的做法是：提前检查表是否存在（
SELECT COUNT(*) FROM user_tables WHERE table_name = UPPER(v_tabname)），避免重复建表；删除前先TRUNCATE再DROP，减少 DDL 失败风险
多环境部署时 Schema 名容易漏写
拼接表名时只写 v_tabname，上线到其他环境可能报 ORA-00942（表或视图不存在）—— 因为开发库默认在当前 Schema 下查，而生产库可能要求显式指定 Schema，比如 'SCOTT.' || v_tabname。
- 统一用
USER视图查当前用户下的对象，避免硬编码 Schema - 跨 Schema 访问时，拼接前确认目标 Schema 有对应权限，且该 Schema 名已通过
DBMS_ASSERT.ENQUOTE_NAME安全校验 - 测试阶段务必在不同 Schema 权限组合下实测，光看编译通过没用
真正麻烦的不是怎么拼，而是拼完之后谁来担保它安全、可回滚、跨环境可用 —— 这些点不提前卡住，上线后修起来比重写还费劲。
