IDE 已经完成编译和产物准备，应用服务器却没有进入部署。真正中断启动的是调试器监听器绑定失败：配置的地址无法绑定，日志提示该地址已被使用。

常见判断是“另一个进程占用了端口”。本次现场却出现了一个容易误导排查的现象：稍后检查时，没有普通进程在监听；Windows 返回的排除 TCP 端口区间却包含这个配置值。只修改调试端口后，完整启动链路恢复。

这说明 Windows 上的固定开发监听器不能只做进程占用检查，还要避开机器当前的动态分配范围和显式排除区间。

先把故障放回启动时序

IDE 启动应用服务器时，会依次跨过多个边界：

编译源码
  -> 构建产物
  -> 绑定调试套接字 …

IDE 在启动应用时弹出告警，提示无法打开运行配置中的 URL。浏览器稍后访问同一路由却能正常显示，应用也已经开始响应真实请求。告警看起来指向应用故障，用户实际依赖的路由却处于健康状态。

一次成功请求不足以解释这组现象。排查需要确认 IDE 检查了什么、检查发生在何时，以及这项控制面检查能否代表用户访问的应用数据面。

告警和应用描述的是两个时刻

运行配置启用了 IntelliJ IDEA 的 After launch，并填写了一个外部 URL。JetBrains 文档说明，该选项会在服务器和配置的产物启动后打开浏览器，URL 字段用于指定目标页面（Tomcat 运行配置）。

现场有四组看似冲突 …

一个本地 WMS 实例的 JDBC 配置明确指向测试数据库，但登录用户、权限和部分页面行为却像来自另一套环境。单看配置文件，很容易得出“应用偷偷连错数据库”的结论。

排查后发现，同一个 Web 应用同时依赖多种数据来源；这些来源指向不同环境，造成了看似数据库串线的现象：

• 业务数据通过 JDBC 访问数据库；
• 登录、用户和权限通过远程 UPM 服务取得；
• Dubbo 服务地址由注册中心或缓存决定；
• Redis 保存会话、权限或服务发现相关缓存；
• 本机还可能同时运行多个 Tomcat，每个实例加载不同的配置目录。

因此，业务列表来自测试库，并不代表权限也来自测试环境。

先确认真正处理请求的进程 …