Spring Boot 的端口和项目路径属于不同配置。升级后路径不生效时，先查属性名；端口“还是旧的”时，则要确认新应用是否真正启动，避免把旧进程的响应当成新配置无效。

端口与上下文路径分别设置

2018 年记录使用过 9090 端口和 /zp 路径。对于 Servlet 应用，Spring Boot 1.5 常见写法是：

server.port=9090
server.context-path=/zp

Spring Boot 2.0 将上下文路径属性放到了 servlet 下：

server.port=9090
server.servlet.context-path=/zp

这是版本差异，不能在同一份配置里堆两套属性来碰运气。Boot 2.0 属性表

假设 Controller 映射 /hello，应用上下文是 /zp，且没有额外的 Servlet 映射或反向代理前缀，那么访问路径为 http://localhost:9090/zp/hello。端口、上下文、DispatcherServlet 映射与 Controller 路径各有作用，不应都当成 Controller 的 RequestMapping。

另一条“端口未生效”记录实际伴随启动失败

另一篇旧记录中，修改配置后访问结果没有变化，日志里同时出现 Redis 连接异常；重新构建后恢复正常。它能说明当时重新构建与成功启动发生在一起，不能证明所有端口问题都需要 clean 或重新打包。

更有用的检查顺序是：

  1. 看本次启动是否出现完整的成功信息，有没有在初始化 Redis、数据库等组件时失败。
  2. 对照本次日志中的监听端口和进程标识，而不是只看浏览器地址栏。
  3. 检查激活的 profile、启动参数、外部配置是否覆盖文件中的值。
  4. 确认请求没有经过另一个进程或代理；部署文件也应与本次构建对应。

Boot 支持外部化配置，多处配置有优先级。因此“文件中写了”只说明一个配置来源的内容，不能单独证明最终取值。外部配置说明

改完后怎样核对

先让应用在预期环境成功启动，再访问一个明确的业务映射；同时对照响应与进程。连接依赖失败时，应处理依赖地址或环境，不要通过反复改端口来掩盖初始化错误。若是 WebFlux 或外置 Servlet 容器部署，还需按对应部署方式核对，不能照搬嵌入式 Servlet 应用的全部假设。