最轻量有效方式是用OracleCredential构造函数传SecureString并设Persist Security Info=false。需去掉连接字符串中的Password和User Id，运行时从安全源获取密码并用AppendChar构建SecureString，Open前设置Credential属性。
直接用 OracleCredential 构造函数传 SecureString，配合连接字符串中禁用明文凭据（Persist Security Info=false），是最轻量且有效的规避方式。 它不依赖外部加密服务或 Wallet，也不需要改数据库配置，适合大多数 .NET 6 + Oracle.ManagedDataAccess 场景。
为什么不能只靠连接字符串加密密码？
很多人尝试把整个连接字符串（含明文密码）用 DPAPI 或 AES 加密后存配置里，再运行时解密拼接——这看似安全，但实际会触发 OracleConnection 内部校验失败。因为一旦连接字符串里出现 Password=xxx 或 User Id=xxx，即使密码是解密后动态拼的，OracleCredential 的 getter 也会被禁用（除非显式设 Persist Security Info=true，但这等于白加一层加密）。更关键的是：这种做法仍让密码在内存中以明文形式存在较长时间，且容易在日志、dump 或调试器中泄露。
-
Persist Security Info=false是硬性前提：它确保连接打开后，Credential属性无法被读取，也阻止连接字符串反向暴露凭据 - 连接字符串中必须去掉
Password和User Id字段，只保留Data Source、Pooling等非敏感项 - 凭据必须通过
OracleCredential对象单独注入，而非拼进连接字符串
如何正确构造并使用 OracleCredential？
.NET 6 中推荐用 OracleCredential(string, SecureString) 构造函数，传入用户名和已转为 SecureString 的密码。注意：密码必须在运行时从安全源（如 Console.ReadKey、Azure Key Vault SDK 返回的 SecureString）获取，不能从明文字符串直接转换（new SecureString() + AppendChar 才合规）。
- 不要用
OracleCredential(string, string)重载——它已被标记为 obsolete，且内部仍会转成明文处理 - 如果需 DBA 权限（如
AS SYSDBA），用OracleCredential(string, SecureString, OracleDBAPrivilege.SysDba) - 创建连接后，必须在
Open()前设置Credential属性；若连接已打开，会抛InvalidOperationException - 示例片段：
var conn = new OracleConnection("Data Source=ORCL;Pooling=true;");
var userName = "appuser";
var password = GetSecurePassword(); // 返回 SecureString
conn.Credential = new OracleCredential(userName, password);
conn.Open(); // 此时才真正认证
常见报错和绕不过去的细节
最常卡在 InvalidOperationException: The connection string has already been set...，本质是连接对象已被初始化过凭据字段。根本原因往往是复用了连接实例、或在 DI 容器中注册了带连接字符串的单例 OracleConnection。
- DI 中不要注册
OracleConnection实例——应注册OracleConnectionFactory或用AddDbContext配合OracleDataSource - 若用
OracleDataSource，它支持WithCredentials方法，比直接操作OracleConnection.Credential更安全 - Windows 上若用 DPAPI 加密密码再转
SecureString，注意DataProtectionScope.CurrentUser绑定的是登录用户 SID，服务账号运行时会失败 -
SecureString无法跨进程/序列化，别试图把它存进 Redis 或写进日志——它设计就是“用完即焚”
真正难的不是怎么加密，而是让密码从进入内存那一刻起就不出现在字符串堆里。所有“先解密再转 SecureString”的方案，都在解密瞬间就破防了。所以优先走系统级凭据管理（如 Windows Credential Manager、Azure Key Vault 的 SecretClient.GetSecretAsync 直接返回 SecureString），而不是自己搞加解密管道。
