一个本地 WMS 实例的 JDBC 配置明确指向测试数据库，但登录用户、权限和部分页面行为却像来自另一套环境。单看配置文件，很容易得出“应用偷偷连错数据库”的结论。
排查后发现，同一个 Web 应用同时依赖多种数据来源；这些来源指向不同环境，造成了看似数据库串线的现象：
- 业务数据通过 JDBC 访问数据库；
- 登录、用户和权限通过远程 UPM 服务取得；
- Dubbo 服务地址由注册中心或缓存决定；
- Redis 保存会话、权限或服务发现相关缓存；
- 本机还可能同时运行多个 Tomcat，每个实例加载不同的配置目录。
因此，业务列表来自测试库，并不代表权限也来自测试环境。
先确认真正处理请求的进程
第一步要把端口、PID、Tomcat 基目录和 Java 命令行对应起来，暂时不要继续改配置。浏览器访问的端口可能属于另一个仍在运行的实例；IDE 中刚启动的进程也可能并不是当前页面请求的接收者。
我把监听端口与进程逐一对应，并检查每个 Java 进程实际加载的 catalina.base、配置目录和外部连接。这个过程暴露出多实例并存：Web 入口和后台服务不是同一个 Tomcat，停止错误的进程只会让页面无法访问，并不会修复环境混用。
不要只检查 JDBC
确认 Web 入口后，排查范围转向运行时依赖。需要分别核对：
- JDBC URL 和当前数据库中的业务数据；
- 注册中心地址以及实际解析出的 Dubbo provider；
- Redis 地址、命名空间和遗留缓存；
- UPM 或单点登录服务的远程地址；
- IDE 启动配置传入的系统属性和环境变量；
- Tomcat 工作目录中是否残留旧配置或展开后的应用。
网络连接同样是证据。进程连接到哪些远端地址，比某个源码目录里的配置文件更能说明运行时事实。
恢复路径与可复用结论
正确做法是保留真正提供页面入口的 Web 实例，然后修正它加载的注册中心、Redis 和权限服务配置。重启前清理或隔离会影响服务发现的缓存，再用端口、进程命令行和实际远端连接验证结果。
这次排障让我再次确认：分布式系统中的“环境”由一组必须保持一致的依赖共同构成，范围远超过单个数据库地址。遇到数据与权限表现不一致时，应先画出请求经过的 JDBC、RPC、缓存和认证路径，再逐段证明当前连接到了哪里。只修改最显眼的配置文件，往往会掩盖真正的运行时分裂。