ORA-28001在Java中于getConnection()时直接失败，需通过SQLException.getErrorCode()==28001或getSQLState()=="72000"稳定识别；修复须满足三条件：独立高权管理连接、预获密码哈希（或提供新密）、连接池支持驱逐旧连接，且改密后必须主动驱逐否则旧连接仍失效。
java程序无法自动捕获并处理ora-28001密码过期异常——它根本不会抛出该错误，而是连接阶段直接失败。 你写的try-catch(sqlexception)捕获不到ora-28001，因为jdbc驱动在建立物理连接时就已拒绝认证，drivermanager.getconnection()直接抛出sqlexception，但sqlstate是72000，错误码是28001，而异常消息字符串才含"password has expired"。靠sqlexception.getsqlstate()或geterrorcode()才能稳定识别。
ORA-28001 在 Java 中的真实触发时机
它不是执行某条SQL时抛的，而是在getConnection()返回前就卡死了。常见表现：
- 应用启动时连接池初始化失败，日志里只有
java.sql.SQLException: ORA-28001: the password has expired - 连接池配置了
connection-test-query（如SELECT 1 FROM DUAL），但测试失败，错误堆栈里没有具体SQL，只有连接建立环节报错 - 调用
Connection.isValid(1)返回false，但不抛异常，也无法得知原因
Java 程序中安全重置密码的必要前提
必须满足三个硬性条件，缺一不可：
- 存在一个独立的、高权限的管理连接（如
sys as sysdba或被授予ALTER USER+CREATE SESSION的专用账号），不能复用当前失效的业务连接 - 业务用户密码哈希值已预先获取（通过
SELECT password FROM user$ WHERE name = 'USER_NAME'），否则无法“重置为原密码”；若允许改新密码，则需业务方提供合规新口令 - 连接池支持主动驱逐指定连接（如HikariCP的
evictConnection()、Druid的removeAbandonedConnection()），否则改密后旧连接仍会持续复用并失败
如何在代码中稳定识别 ORA-28001 并触发修复流程
不要依赖异常消息字符串匹配（易受NLS语言影响），应检查SQLException的结构化字段：
if (e instanceof SQLException) {
SQLException sqle = (SQLException) e;
if (sqle.getErrorCode() == 28001 || "72000".equals(sqle.getSQLState())) {
// 确认是密码过期，启动修复流程
handlePasswordExpiration(targetUser, adminDataSource);
}
}
注意：getSQLState()在Oracle JDBC中更可靠，因getErrorCode()可能被包装层覆盖；getMessage().contains("expired")在中文环境会失效。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
修改密码后旧连接不自动失效，这是最常被忽略的点
执行ALTER USER ... IDENTIFIED BY VALUES 'xxx'后，所有已建好的JDBC连接仍持有旧会话凭证，它们不会感知密码变更。下一次从连接池取连接时，如果连接还活着，就会继续用旧密码通信——直到该连接因网络中断、超时或验证失败被关闭。这意味着：
- 不能只改密码就认为问题解决
- 必须在改密后立即调用连接池的驱逐接口，把所有属于该用户的连接标记为无效
- 若连接池未启用
validate-on-borrow，这些旧连接可能在后续业务请求中突然抛出ORA-01017（invalid username/password）
真正可靠的闭环是：检测到ORA-28001 → 拿到哈希 → 用admin连接执行ALTER USER ... IDENTIFIED BY VALUES → 调用evictConnection()清理池中全部对应连接 → 下次业务请求将新建连接并成功认证。
