孙玲的空间1. 项目背景与问题概述
去年接手公司"苍穹外卖"系统的迁移任务时，我本以为只是简单的服务器搬迁。没想到从开发环境切换到生产环境的过程中，遭遇了JDK版本冲突、多数据源配置异常、端口占用以及JWT鉴权失效等一系列连环问题。这些问题就像多米诺骨牌，解决一个又引发另一个，整整耗费了我们团队三天时间才完全排查清楚。
这个案例非常典型地展示了企业级项目迁移中的常见陷阱。很多开发者在本地测试环境跑得顺畅的系统，一旦部署到新环境就会出现各种"玄学"问题。本文将完整还原当时的排查过程，重点分析四个核心问题点的解决方案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. JDK版本引发的编译灾难
2.1 环境差异导致的构建失败
迁移后的第一道坎出现在项目构建阶段。本地开发使用的是JDK 8，而新服务器预装的是JDK 17。控制台报出令人窒息的错误：
code复制It is configured to use JDK 0, but IDE supports compilation using JDK 7 and...
这个看似荒谬的报错信息背后，实际是Maven编译插件版本与JDK的兼容性问题。我们的pom.xml中使用了较老的maven-compiler-plugin（3.1版本），它在高版本JDK环境下会出现识别异常。
2.2 解决方案与版本选择
经过测试，我们最终采用以下组合方案：
- 升级maven-compiler-plugin到3.8.1版本
- 在pom.xml中显式指定编译参数：
xml复制<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>17</source>
<target>17</target>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
</configuration>
</plugin>
关键经验：永远不要依赖系统默认的JDK版本。建议在Dockerfile或部署脚本中强制指定JDK下载路径，例如使用Azul Zulu JDK的镜像源确保一致性。
3. 多数据源配置的暗坑
3.1 Druid连接池的初始化异常
项目使用MyBatis+Druid管理多个数据源，在本地测试时运行正常。但迁移后出现连接泄漏警告：
code复制[ERROR] [Druid-ConnectionPool-Create-1] com.alibaba.druid.pool.DruidDataSource - create connection error
查看详细日志发现是数据库时区设置不一致导致。本地MySQL使用系统时区，而生产环境MySQL配置了UTC时区。
3.2 多环境配置方案优化
我们在application-prod.yml中增加了时区参数：
yaml复制spring:
datasource:
druid:
master:
url: jdbc:mysql://localhost:3306/waimai?useSSL=false&serverTimezone=Asia/Shanghai
slave:
url: jdbc:mysql://replica:3306/waimai?useSSL=false&serverTimezone=UTC
同时修正了Druid的监控页面配置：
java复制@Configuration
public class DruidConfig {
@Bean
public ServletRegistrationBean<StatViewServlet> statViewServlet() {
ServletRegistrationBean<StatViewServlet> bean =
new ServletRegistrationBean<>(new StatViewServlet(), "/druid/*");
// 添加IP白名单
bean.addInitParameter("allow", "192.168.1.100,127.0.0.1");
// 控制台管理用户
bean.addInitParameter("loginUsername", "admin");
bean.addInitParameter("loginPassword", "123456");
return bean;
}
}
4. 端口冲突的诡异表现
4.1 WebSocket服务的绑定失败
系统需要启动WebSocket服务在10080端口，但报错：
code复制Windows socket error: 通常每个套接字地址(协议/网络地址/端口)只允许使用一次
使用PowerShell快速检测端口状态：
powershell复制Test-NetConnection -ComputerName localhost -Port 10080
发现是Ubuntu系统自带的Snap版Chrome浏览器占用了该端口。这个冷门问题在Windows环境从未出现过。
4.2 端口管理最佳实践
我们最终采用的解决方案：
- 修改WebSocket服务端口为10081
- 在Nginx配置端口转发：
nginx复制server {
listen 10080;
location / {
proxy_pass http://localhost:10081;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
同时整理了端口检测命令备忘：
- Windows:
netstat -ano | findstr 10080 - Linux:
ss -tulnp | grep 10080 - 跨网络测试:
telnet 192.168.1.100 10080
5. JWT鉴权失效的深度排查
5.1 Token续签机制的BUG
迁移后前端频繁收到401未授权错误。通过在线JWT解析工具检查发现，虽然token未过期，但服务端始终拒绝验证。
根本原因是新旧环境系统时钟不同步。本地开发机时钟快了3分钟，而生产服务器使用NTP同步，导致token的iat(签发时间)被误判为未来时间。
5.2 JWT验证逻辑加固
改造JWT工具类，增加时钟偏移容错：
java复制public class JwtUtil {
private static final long CLOCK_SKEW = 180; // 3分钟容差
public static boolean verify(String token) {
try {
Jwts.parserBuilder()
.setAllowedClockSkewSeconds(CLOCK_SKEW)
.setSigningKey(key)
.build()
.parseClaimsJws(token);
return true;
} catch (Exception e) {
log.error("JWT验证失败: {}", e.getMessage());
return false;
}
}
}
同时完善了token续签策略：
- 当剩余有效期小于30分钟时自动续签
- 续签后的新token通过response header返回：
java复制response.setHeader("X-Renew-Token", newToken);
6. 系统化预防方案
经历这次迁移磨难后，我们建立了环境检查清单：
-
基础环境验证
- JDK版本一致性检查脚本
- 系统时钟同步状态监控
- 端口占用预扫描工具
-
配置管理改进
- 使用Spring Cloud Config集中管理多环境配置
- 数据源参数加密存储
- 部署前配置差异对比
-
监控增强
- Druid连接池健康指标接入Prometheus
- JWT失效日志实时告警
- WebSocket连接状态可视化
这套预防机制在后来的三次迁移中，将平均故障处理时间从8小时缩短到30分钟以内。特别是通过Ansible自动化执行预检脚本，可以提前发现90%的环境兼容性问题。