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