ORA-01017 在 .NET Core 中本质是凭据字节级不一致：密码大小写敏感（SEC_CASE_SENSITIVE_LOGON=TRUE）、连接字符串引号/转义错误、BOM/空格等隐性字符、账户锁定或权限缺失、PDB上下文错误、客户端协议版本不兼容均会导致该错。
ORA-01017 在 .NET Core 场景下几乎总是“连得上、验不过”——TCP 握手成功，但 Oracle 服务端明确拒绝认证。问题不出在网络或驱动加载，而集中在凭据传递的字节级一致性上。
SQL*Plus 能连通但 .NET Core 报错，先查 SEC_CASE_SENSITIVE_LOGON
Oracle 11g 起默认开启密码大小写敏感，SEC_CASE_SENSITIVE_LOGON = TRUE 意味着：
- 密码必须字节完全一致：大小写、空格、BOM、末尾换行符全参与比对
- Windows 记事本/邮件复制的密码常带 UTF-8 BOM，
sqlplus不报错但Oracle.ManagedDataAccess会原样传给服务端 - 用
SHOW PARAMETER sec_case_sensitive_logon;查当前值；若为TRUE，临时关闭验证：ALTER SYSTEM SET sec_case_sensitive_logon = FALSE SCOPE=BOTH; - 关掉后建议立即重设一次密码（哪怕内容不变）：
ALTER USER scott IDENTIFIED BY "TiGeR@123";，避免旧哈希与新策略不兼容
Oracle.ManagedDataAccess 连接字符串中的引号和转义陷阱
.NET Core 的连接字符串对符号极其敏感，错一处就导致凭据被截断或标准化：
- 用户名含小写字母或下划线？必须加英文双引号：
User Id="my_user";，否则 Oracle 当作MY_USER - 密码含
@、/、:、$？必须用英文双引号包裹：Password="Pass@123"; - C# 普通字符串里反斜杠要双写：
Password="pass\word";；更稳妥用逐字字符串：@'User Id=scott; Password="TiGeR@123"; Data Source=orcl;' - 从
appsettings.json或环境变量读取？务必调用.Trim()，尤其 Windows 配置文件常带 BOM 或尾部空格
账户状态、权限和 PDB 上下文被统一掩盖为 ORA-01017
Oracle 在认证流程中不区分“密码错”和“账户锁死”，都返回 ORA-01017：
- 查真实状态：
SELECT username, account_status FROM dba_users WHERE username = 'SCOTT';，EXPIRED & LOCKED或LOCKED都会导致该错误 - 确认权限：
SELECT * FROM dba_sys_privs WHERE grantee = 'SCOTT' AND privilege = 'CREATE SESSION';，缺失则补：GRANT CREATE SESSION TO scott; - Oracle 12c+ 是多租户架构，确保连接串指向的是 PDB（如
orclpdb），不是 CDB root；检查tnsnames.ora中的服务名是否匹配
客户端协议版本不兼容也会伪装成 ORA-01017
Oracle 12.2+ 默认启用更强的密码验证协议，老客户端（如 12.1c 客户端连 12.2c 服务端）可能协商失败，表面就是 ORA-01017：
- 在数据库服务器的
$ORACLE_HOME/network/admin/sqlnet.ora中添加：SQLNET.ALLOWED_LOGON_VERSION_SERVER=12（或更低兼容值，如11） - 重启监听：
lsnrctl restart - 执行后仍需重设一次用户密码：
ALTER USER myuser IDENTIFIED BY mypassword;，触发新协议哈希重生成
最易被忽略的是：密码从配置文件读取时的隐性字符（BOM、空格、换行），以及连接池复用失败连接导致后续请求持续报错。别只盯着“密码对不对”，要盯住“传进去的到底是什么字节”。
