ora-01008错误源于sql中绑定变量未全部赋值，主因包括注释或字符串中冒号被误识别、execute immediate using参数数量/顺序不匹配、jdbc preparedstatement重复传sql字符串、null值未正确处理等。
SQL里混了注释或字符串字面量中的冒号
Oracle在词法分析阶段就会扫描整个SQL文本，把所有 : 开头的标识符都算作绑定变量——哪怕它藏在注释里、单引号字符串里、甚至PL/SQL块中。比如这句：
SELECT * FROM emp WHERE id = :id -- 这里写了个 :ignore_me
Oracle会认为有两个绑定变量：:id 和 :ignore_me，但代码只绑了 :id，立刻触发ORA-01008。
- 检查SQL是否含
-- :xxx或/* :xxx */类注释 - 确认字符串字面量（如
'UPDATE :table SET x=1'）里没意外带冒号 - 用
INSTR(sql, ':')或正则粗筛，再人工核对每个冒号是否真该绑定
EXECUTE IMMEDIATE USING 参数数量或顺序错
PL/SQL里用 EXECUTE IMMEDIATE 执行动态SQL时，USING 子句必须严格匹配SQL中绑定变量的个数、顺序和类型。命名绑定（:a, :b）在PL/SQL里不支持“按名传递”，只认位置。
- SQL里有3个
?或3个:var，USING就必须提供3个值，缺一不可 -
USING IN参数不能为NULL，否则视为未绑定；需显式传NULL时用USING IN var_name并确保变量已声明且可为空 - 避免在同一个SQL里重复使用同一变量名（如
WHERE x=:id AND y=:id），PL/SQL仍只算1个绑定位，但某些驱动可能误判
JDBC PreparedStatement 执行时多传了SQL字符串
这是Java里最隐蔽的坑：调用 executeUpdate(sql) 或 executeQuery(sql) 时，把原始SQL字符串又传了一次。PreparedStatement早已预编译好，再传SQL会导致Oracle忽略绑定参数，直接按字面量解析，? 变成未识别符号。
- 正确写法只有
ps.executeUpdate()或ps.executeQuery()，括号内**必须为空** - 错误写法：
ps.executeUpdate("UPDATE t SET x=? WHERE y=?")—— 即使参数已set，也必报ORA-01008 - 如果用的是Spring JDBC或MyBatis，检查是否误配了
sql属性而非args参数
绑定参数值为 null 且未转为 DBNull.Value
Oracle驱动（尤其是ODP.NET）对 null 值敏感：传 null 会被当作“未赋值”，而非“空值”。即使参数名、数量全对，只要有一个是裸 null，就判定为未绑定。
- C#中必须统一处理：
if (param.Value == null) param.Value = DBNull.Value; - Java里用
pstmt.setNull(index, sqlType)，别用setObject(index, null) - Python cx_Oracle中，
None是合法空值，但若SQL含多个:x，每个都要显式传None，不能省略
实际排查时，先打印 cmd.Parameters.Count（C#）或 ps.getParameterMetaData().getParameterCount()（Java），再逐个比对名称和值——最容易被忽略的是注释里的冒号和执行方法多传的SQL字符串。
