OracleParameter 是 .NET 中防范 SQL 注入的强制要求，必须将 CommandText 设为静态 SQL，所有参数通过 Parameters 传入，命名绑定需严格匹配 :param_name，动态结构（如表名）须白名单校验。
OracleParameter 是 .NET 中防 SQL 注入的唯一可靠路径
直接拼接字符串构造
，哪怕只加一个单引号，就等于把数据库大门钥匙交给攻击者。.net 的
不是“可选增强”，而是
oracle
场景下防止注入的强制要求——它让数据库驱动在协议层就把用户输入当纯数据处理，不参与 sql 解析，从根本上切断执行链。
为什么不能用 string.Format 或 $"" 拼接 Oracle SQL
常见错误是把参数化当成“加个占位符就行”，结果仍用字符串插值生成 SQL：
这种写法中，
已在拼接时被注入，
后续添加毫无意义。必须保证
是静态 SQL 字符串，所有变量都通过
传入。
中的占位符必须是
（Oracle 命名绑定）或
（位置绑定），不能是
或
使用命名绑定时，
构造函数第一个参数必须与 SQL 中的
完全一致，大小写敏感
Oracle 驱动对
的位置绑定支持较弱，尤其涉及
或 PL/SQL 块时易出错，优先用命名绑定
动态表名/列名等无法参数化的场景怎么办
只能保护“值”，无法保护 SQL 结构本身。遇到
或
这类需求，必须启用白名单校验：
提取输入后，用正则
严格匹配标识符格式
查数据库字典视图
或
确认该名称真实存在且属于当前 schema
禁止任何含点号（
）、双引号（
）、美元符（
）的输入，Oracle 对 quoted identifier 的解析逻辑复杂，极易绕过校验
例如排序字段
必须先过白名单，再拼进 SQL：
，而非尝试用
绑定。
oracle知识库
oracle知识库下载
下载
容易被忽略的 Oracle 特有陷阱
Oracle 的字符集、NLS 设置和驱动版本会悄悄破坏参数化效果：
使用
时，确保连接字符串含
，否则中文参数可能被截断或乱码，导致应用层重试时改用拼接
Oracle 12c+ 支持
等新函数，但若参数传入 JSON 字符串，需手动调用
类型，否则驱动可能降级为字符串处理，丢失类型安全
PL/SQL 存储过程中调用
时，即使外部用了
，内部拼接仍会引入风险——必须在存储过程内也用
子句传递参数
最隐蔽的问题是：Oracle 错误堆栈里出现
，往往不是参数名写错，而是
在执行前被清空或重复添加，导致绑定失效。调试时务必检查
是否与 SQL 中占位符数量一致。
oraclecommand.commandtextoracleparameter// ❌ 危险：拼接发生在 C# 层，OracleParameter 未生效
string sql = $"SELECT * FROM users WHERE name = '{name}'";
cmd.CommandText = sql;
cmd.Parameters.Add(new OracleParameter("p1", name)); // 这行完全没用nameOracleParameterCommandTextParametersCommandText:param_name?@p${}OracleParameter:xxx?REF CURSOROracleParameterORDER BY :colFROM :table^[a-zA-Z][a-zA-Z0-9_]{0,29}$ALL_TAB_COLUMNSALL_TABLES."$sortFieldORDER BY " + validatedSortFieldOracleParameterOracle.ManagedDataAccessUnicode=TrueJSON_VALUEOracleDbType.JsonEXECUTE IMMEDIATEOracleParameterUSINGORA-01036: illegal variable name/numberCommand.ParametersParameters.Count