ORA-01017 连接失败大概率因 SEC_CASE_SENSITIVE_LOGON=TRUE 导致密码大小写/空格/特殊字符校验失败；需用 SQL*Plus 命令行验证、检查引号与BOM、临时关闭参数或重置密码定位。
ora-01017 报错时，密码“明明没输错”却连不上，大概率是 sec_case_sensitive_logon 设置导致的认证字节比对失败——不是客户端错了，是 oracle 服务端在严格校验大小写。
检查 SEC_CASE_SENSITIVE_LOGON 当前值
先确认数据库是否真启用了大小写敏感：
SHOW PARAMETER sec_case_sensitive_logon;
如果返回 TRUE，说明密码必须完全匹配（包括大小写、空格、特殊字符），且该设置从 Oracle 11g 起默认开启。注意：SQL*Plus 某些旧版本可能因兼容层掩盖差异，而 Oracle.ManagedDataAccess 或 cx_Oracle 会直接暴露不一致。
用 SQL*Plus 直连验证是否为大小写问题
不要依赖图形工具或配置文件，用命令行强制控制输入环境：
- 输入全小写密码测试：
sqlplus scott/tiger@orcl - 再用双引号包裹原始密码（含大写/符号）：
sqlplus "scott/TiGeR@123"@orcl - 若前者失败、后者成功，基本锁定为大小写敏感导致
特别注意：Windows 下从记事本或邮件复制密码，极易带 BOM 或末尾换行符，sqlplus 里粘贴后看似一样，实际多一个
—— 这种错误 sqlplus 不报，但 .NET 驱动会严格传给 Oracle 并比对失败。
临时关闭大小写敏感以快速验证
如果你有 SYSDBA 权限，可在数据库中执行（无需重启实例）：
ALTER SYSTEM SET sec_case_sensitive_logon = FALSE SCOPE=BOTH;
执行后立即生效，所有新连接跳过大小写校验。但注意：
-
SCOPE=BOTH是关键，否则只影响当前会话，重启后失效 - 执行后建议重置一次密码（哪怕设成一样的）：
ALTER USER scott IDENTIFIED BY "TiGeR@123";，避免旧哈希与新策略不兼容 - 生产环境不建议长期关闭，仅用于定位和过渡
.NET 连接字符串中用户名和密码的引号陷阱
Oracle.ManagedDataAccess 对引号处理非常敏感，不加或错加都会导致认证字符串被截断或标准化：
- 用户名含小写字母或下划线？必须加双引号：
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 上 UTF-8 BOM 常导致开头多出不可见字符
最隐蔽的坑：连接池默认开启，首次认证失败的连接句柄可能被复用，后续 Open() 仍报 ORA-01017，误以为是新问题。排查时可临时加 Pooling=false; Connection Timeout=5; 隔离。
复杂点在于，SEC_CASE_SENSITIVE_LOGON 的影响不是孤立的——它和密码存储格式（PASSWORD_VERSIONS）、用户创建方式（是否用双引号）、客户端驱动版本、甚至 TNS 解析顺序都耦合在一起。单改一项可能无效，必须同步验证 v$services、dba_users.account_status 和连接字符串最终拼接结果。
