oracle动态sql中表名、列名等结构元素不可用绑定变量，因解析器在硬解析阶段即校验语法，ora-00903/ora-01027等属解析错误；绑定变量仅适用于where、values、set等值上下文，结构拼接须用白名单或dbms_assert校验。
Oracle 动态 SQL 中不能用 :table_name 或 :col 绑定表名、列名，这不是语法疏漏，而是解析器硬性限制——它根本不会把这类占位符当“结构”来处理。
ORA-00903 / ORA-00904 不是运行时报错，而是解析失败
当你写 EXECUTE IMMEDIATE 'SELECT * FROM :t' USING v_table;，Oracle 在硬解析阶段就直接报 ORA-00903: invalid table name。不是执行时查不到表，是 SQL 字符串还没进执行引擎，就被语法校验拦下了。同理，ORDER BY :sort_col 会触发 ORA-01027，因为 ORDER BY 后必须是确定的标识符，不是值占位符。
- 绑定变量（
:var）只在WHERE、VALUES、SET等值上下文中合法 -
FROM、SELECT列列表、GROUP BY、UNION子句这些地方，压根不接受绑定语法 - 错误信息里带 “invalid identifier” 或 “invalid table name”，基本可断定是结构拼接问题，不是数据问题
为什么设计上死卡这一条？缓存和权限都靠它立住
如果允许 :table 指向任意表，同一段 SQL 字符串（比如 SELECT * FROM :t）可能今天查 orders，明天查 users。那 Oracle 就没法复用执行计划：索引选哪个？统计信息用哪套？并行度设多少？全乱套。更致命的是权限检查失效——用户 A 有 t_order 权限，没 t_user 权限，但只要能控制 :t，就能绕过静态权限校验。
- 执行计划缓存依赖 SQL 字符串完全一致，动态对象名等于主动放弃缓存
- 权限校验发生在硬解析阶段，此时动态拼出的对象名还没出现，数据库无从判断该不该放行
- DBMS_ASSERT 包（如
DBMS_ASSERT.SQL_OBJECT_NAME）就是为填补这个校验缺口而生的
安全拼接的实操底线：白名单 > 数据字典 > DBMS_ASSERT
拼接本身很简单，难的是证明拼出来的字符串绝对合法。别信“我用正则过滤了分号和单引号”——Unicode 零宽空格、注释嵌套、双引号绕过都能打穿它。
- 优先走白名单：
CASE v_sort_field WHEN 'name' THEN 'name' WHEN 'created_at' THEN 'created_at' ELSE NULL END，非列表值直接拒掉 - 查数据字典要严格限定 schema：
SELECT 1 FROM all_tables WHERE owner = 'MY_SCHEMA' AND table_name = UPPER(v_input) -
DBMS_ASSERT.SIMPLE_SQL_NAME(v_name)会拒绝含点、空格、引号、分号的输入，但注意它不校验对象是否存在 - 拼完记得大写+双引号包裹（如
"' || v_table || '"），否则小写名或带下划线的名可能解析失败
最容易被忽略的坑：看似参数化，实则全程裸奔
很多人以为写了 USING 就算安全了，其实只要拼接发生在 EXECUTE IMMEDIATE 的字符串里，就和绑定无关。
-
v_sql := 'SELECT * FROM ' || v_table; EXECUTE IMMEDIATE v_sql USING v_param;——USING对v_table完全无效 -
'ORDER BY ' || user_input即使后面跟USING，照样 SQL 注入，因为排序字段不属于值上下文 - 用
TO_CHAR或REPLACE清洗输入？攻击者早就有绕过方案，别赌这个
真正难的从来不是“怎么让代码跑起来”，而是“怎么让审计人一眼确认这段拼接不可能指向非法对象”。白名单和 DBMS_ASSERT 是目前 Oracle 生态里最经得起推敲的两条路。
