必须用 DBMS_SQL.DESCRIBE_COLUMNS 获取列元信息，因 EXECUTE IMMEDIATE 要求预知列数与类型，无法处理动态列；需先 OPEN_CURSOR、PARSE，再 DESCRIBE_COLUMNS 获取 desc_tab，依 col_type 动态 DEFINE_COLUMN，最后安全 CLOSE_CURSOR。
直接用 DBMS_SQL 执行未知列的查询是可行的，但必须跳过「提前声明接收变量」这一步——因为列名、类型、数量全未知，硬编码 v_name、v_date 会立刻报错。
为什么不能用 EXECUTE IMMEDIATE 获取未知列结果？
EXECUTE IMMEDIATE 要求你提前知道返回几列、每列什么类型，否则编译就失败。比如 EXECUTE IMMEDIATE 'SELECT * FROM t' INTO ...，省略 INTO 部分会报 ORA-00905；写了又得一一匹配，根本没法应对「列动态变化」的场景。
-
EXECUTE IMMEDIATE对SELECT必须有INTO或BULK COLLECT INTO，没得绕 - 它不提供「先看结构、再读数据」的中间态，解析失败就直接抛异常，无法干预
- 哪怕加了
WHERE 1=0，DML/DDL 仍会真实执行（如删空表、建临时索引），风险不可控
必须用 DESCRIBE_COLUMNS 获取列元信息
核心动作是调用 DBMS_SQL.DESCRIBE_COLUMNS，它把运行时解析出的列名、类型、长度等写进 dbms_sql.desc_tab 类型的集合里，后续才能按需定义接收变量。
- 调用前必须先
PARSE，且不能跳过OPEN_CURSOR——游标未打开就调DESCRIBE_COLUMNS会报 ORA-01001 -
col_type字段值对应 Oracle 内部类型码：1=VARCHAR2，2=NUMBER，12=DATE，100=BOOLEAN（极少用），需逐个判断分支处理 - 如果 SQL 含表达式（如
UPPER(name)），col_name可能为空或为"UPPER(NAME)"，不能直接当字段名用
DEFINE_COLUMN 必须按类型动态分配长度
DEFINE_COLUMN 的第三个参数（长度）对字符类型是强制的，但传小了会截断，传大了浪费内存；对 NUMBER/DATE 类型可省略，但显式写出更安全。
- VARCHAR2 列必须传足够长度：用
desctab(i).col_max_len，不是随便写 100 或 4000 - NUMBER 列建议统一用
NUMBER(38)接收，避免ORA-06502精度溢出 - DATE 列直接用
DATE类型变量，别试图用VARCHAR2中转格式化 - 遇到
col_type = 112（CLOB）或113（BLOB），得换用DEFINE_COLUMN_LONG，否则 fetch 时崩
CLOSE_CURSOR 前务必检查游标状态
很多脚本在异常路径里无条件调 DBMS_SQL.CLOSE_CURSOR，但若游标根本没成功打开（比如 PARSE 失败），关它就会触发 ORA-01001，掩盖原始错误。
- 始终用
DBMS_SQL.IS_OPEN(curid)判断后再关，别信「肯定打开了」 - 不要依赖 EXCEPTION 块里的
CLOSE_CURSOR保底——万一OPEN_CURSOR都失败了，curid是 NULL，关它照样报错 - 真正容易被忽略的是：同一个游标号重复
OPEN_CURSOR不报错，但后续PARSE会覆盖旧状态，旧结果集丢失且不可回溯
