OracleCommand.CommandType = CommandType.StoredProcedure 生效的前提是：存储过程名与CommandText完全一致（含大小写、包名），参数名、方向、类型须与PL/SQL端严格匹配，且连接字符串必须包含Unicode=True以确保字符串正确传输。
OracleCommand.CommandType = CommandType.StoredProcedure 为什么没生效
常见现象是调用后无报错但存储过程没执行，或返回空结果。根本原因不是 commandtype 设错了，而是没配对：oracle 存储过程名必须和 commandtext 完全一致（含大小写、包名），且参数名、方向、类型必须与 pl/sql 端严格匹配。
-
CommandText应设为"pkg_name.proc_name"（带包名）或"proc_name"（无包），不能是"call pkg_name.proc_name()"或带begin/end - Oracle 不靠函数签名推断参数，
OracleParameter的ParameterName必须和存储过程中定义的参数名**完全一致**（区分大小写），哪怕只差一个下划线也会绑定失败 - 如果存储过程有
OUT或IN OUT参数，Direction必须显式设为ParameterDirection.Output或ParameterDirection.InputOutput，不能省略
IN/OUT 参数怎么传才不报 ORA-06502 或 ORA-01008
ORA-06502 多半是类型不匹配（比如 C# 传 int，PL/SQL 期望 NUMBER(1)），ORA-01008 是“未绑定变量”，本质是参数名拼错或漏加 OracleParameter。
-
OracleParameter构造时，OracleDbType要尽量选精确类型：OracleDbType.Varchar2对应VARCHAR2，OracleDbType.Int32对应NUMBER(10)，别全用OracleDbType.Decimal - 对于
REF CURSOR输出参数，必须用OracleDbType.RefCursor，且不能设Value；执行后需用OracleDataAdapter或ExecuteReader()拿结果集 - 如果存储过程定义了默认值的参数，C# 仍需显式添加该参数并设
Value = DBNull.Value，否则 Oracle 认为“未提供”，可能触发 ORA-01008
连接字符串里要不要加 Unicode=true
要加，尤其当存储过程处理中文、特殊符号或使用 NVARCHAR2 类型时。不加可能导致乱码或隐式转换失败，且错误常不直接报在执行阶段，而是在取 OUT 值时崩掉。
- 连接字符串中明确加上
Unicode=True（如"Data Source=...;User Id=...;Password=...;Unicode=True;"） - 即使数据库字符集是 AL32UTF8，.NET 驱动默认仍按非 Unicode 方式编码字符串，
Unicode=True才启用 UTF-16 ↔ UTF-8 正确转换 - 这个配置不影响
CommandType行为，但会影响所有字符串参数的传输准确性，漏掉它，前面参数全对也白搭
执行后读不到 REF CURSOR 返回的数据集
不是没返回，是没用对方式。Oracle 的 REF CURSOR 不能像 SQL 查询那样直接 ExecuteScalar() 或当普通输出参数取值，它本质是个游标句柄，得用数据适配器或专门的读取逻辑。
- 确保
OracleParameter的OracleDbType是RefCursor，Direction是Output - 执行完
ExecuteNonQuery()后，不能直接访问Parameter.Value—— 它是OracleRefCursor对象，得用OracleDataAdapter.Fill()或OracleCommand.ExecuteReader()才能转成DataTable或OracleDataReader - 如果用
ExecuteReader()，注意它会自动消耗第一个REF CURSOR，多个输出游标需用NextResult()切换
Oracle 存储过程调用真正卡住的地方，从来不在 CommandType 这一行代码上，而在参数名是否和 PL/SQL 里一模一样、OracleDbType 是否精确、连接字符串有没有 Unicode=True——这三个点漏一个，调试时就容易绕半天。
