苍穹外卖项目迁移中的连环报错排查：JDK、数据源、端口和JWT

最近在跑苍穹外卖项目时，原本以为只是把环境配一下就能启动，结果一路踩了好几个坑。表面上看是零散的小问题，实际上它们是串起来的：前一个问题不解决，后一个问题根本暴露不出来。

其他基础的一些报错可以参考这篇别人写的，我觉得还是挺不错的，他也是按照课程学习进度写的一些报错和解决办法：苍穹外卖问题记录（持续更新）-CSDN博客

这里还有其他人记的一些笔记：苍穹外卖项目总结_苍芎外卖如何实现的跨域-CSDN博客

这次排查下来，我最大的感受是：很多Java项目启动失败，并不是“代码有问题”，而是“环境、配置和依赖版本之间没有对齐”。下面按我真实排查的顺序，把这几个问题和解决过程整理一下。

##1.Maven编译直接失败：不支持发行版本22

最先遇到的是编译错误：[ERROR]Failedtoexecutegoalorg.apache.maven.plugins:maven-compiler-plugin:3.14.0:compile

[ERROR]Fatalerrorcompiling:错误:不支持发行版本22

这个报错的意思其实很直接：项目在pom.xml里把编译版本设置成了22，但我本机实际使用的是JDK17，所以Maven在编译时找不到对应的发行版本支持。

一开始这类问题很容易误判成“是不是Maven坏了”或者“是不是环境变量没生效”，但本质上就是项目要求的Java版本和本地JDK版本不一致。###解决方式

我直接把父pom.xml里的Java编译配置统一改成了17，包括：

-maven.compiler.source

-maven.compiler.target

-maven-compiler-plugin里的source/target/release

-额外补了一个java.version=17

像这种项目，如果代码本身并没有用到Java21、22的新特性，那我更倾向于优先降到LTS版本，而不是为了编译通过再去硬装一个JDK22。因为从维护角度看，17明显更稳，兼容性也更好

##2.编译通过了，启动又失败：DataSource没配出来

JDK版本对齐后，mvncompile是通过了，但应用启动又报了新的错误

FailedtoconfigureaDataSource:'url'attributeisnotspecified

Reason:Failedtodetermineasuitabledriverclass

看到这个错误时，我第一反应是数据库没配。但继续看配置文件后，发现事情没那么简单。

项目里其实有数据库相关配置，只不过写法有点“分裂”：

-一部分写在spring.datasource.druid.*

-一部分写在自定义的sky.datasource.*

问题在于，SpringBoot3启动时并没有从这些配置里正确拼出一个标准的数据源对象，所以最后表现出来就是：它觉得你根本没配url。

###解决方式

我把数据源配置调整成SpringBoot能直接识别的标准写法

-spring.datasource.driver-class-name

-spring.datasource.url

-spring.datasource.username

-spring.datasource.password

然后再通过占位符去读取application-dev.yml中已有的sky.datasource.*配置。

我个人比较推荐这种做法：业务自定义配置可以保留，但框架核心能力尽量走标准配置键。因为框架升级以后，最先出兼容性问题的，往往不是代码逻辑，而是这些“看起来还能用、实际上已经不稳定”的配置方式。

##3.数据源问题解决后，又被8080端口占用卡住了数据源配置修完之后，应用已经能走到Tomcat启动阶段了，结果又报：

Webserverfailedtostart.Port8080wasalreadyinuse.

这类问题其实不复杂，但很常见。尤其是本地开发时，之前启动过一个服务忘记关，或者别的应用刚好占了这个端口。

###解决方式

先查端口占用：netstat-ano|findstr:8080找到监听进程的PID后，再结束它：taskkill/PID7796/F确认8080不再处于LISTENING状态后，服务就能继续启动了。这个问题虽然简单，但它提醒了我一件事：排查启动问题不要想一步到位，很多时候就是“清一个障碍，才会露出下一个障碍”。如果前面就开始怀疑代码逻辑，反而容易把自己带偏。

##4.登录时报JWT异常：WeakKeyException项目终于启动起来了，结果登录后台时又炸了。

这次日志指向得很明确：

io.jsonwebtoken.security.WeakKeyException:Thespecifiedkeybytearrayis48bitswhichisnotsecureenoughforanyJWTHMAC-SHAalgorithm

说白了就是：JWT的密钥太短了。

项目原来的配置里，JWT密钥是：admin-secret-key:itcast这在旧版本依赖里可能还能跑，但现在升级到jjwt0.11.5之后，HS256算法要求密钥长度至少256bit，也就是至少32字节左右。

itcast这种6个字符的字符串显然不够。

###解决方式

我没有去改JwtUtil的生成逻辑，而是直接改配置，把密钥换成足够长的值，比如：sky:jwt:admin-secret-key:sky-admin-secret-key-2026-secureadmin-ttl:7200000admin-token-name:tokenuser-secret-key:sky-user-secret-key-2026-secureuser-ttl:7200000user-token-name:authentication

这里我顺手把用户端的JWT配置也补齐了。原因很简单：如果现在只修后台登录，那后面一旦接入用户端登录，大概率还会因为同样的问题再报一次。我的习惯是，发现同类问题已经有扩散趋势时，宁可一次性补完整，也不要只修眼前这一处。

小结一下：

###1.不要把“能编译”和“能启动”混为一谈很多人觉得mvncompile通过了，项目应该就差不多了。其实完全不是一回事。-编译通过，说明源码和依赖在语法层面没问题-能启动，说明配置、环境、端口、外部资源也都对上了-能登录，才说明业务链路开始打通-能正常使用，才算真的跑起来这次就是一个很典型的例子：编译问题、数据源问题、端口问题、JWT问题，分别出现在不同阶段。

###2.配置比代码更容易在升级时出问题这次真正动代码的地方几乎没有，主要修的都是配置。说明很多老项目在升级SpringBoot、JDK或第三方依赖时，最脆弱的往往不是业务代码，而是：-pom.xml-application.yml-环境变量-IDE/Maven/JDK的版本对齐这些地方平时不显眼，但一旦版本变了，它们反而最先出问题。

###3.框架升级后，旧写法“不是不能用”，而是“不值得赌”比如这次的数据源配置、JWT密钥长度，本质上都属于这种情况。旧项目里也许能跑，但一升级版本，就会暴露出边界问题。我的看法是：如果已经决定升级，就尽量往新版本推荐的方式靠，不要一直抱着旧写法不放。短期看是少改一点，长期看反而更麻烦。

解决：

1.把Maven的Java编译版本统一改成17

2.调整SpringBoot数据源配置，让dev环境下能正确读取数据库连接信息

3.结束占用8080的进程，释放本地端口

4.把JWT的短密钥改成符合HS256要求的安全长度，并补齐用户端配置处理完之后，项目已经可以正常编译、启动，后台登录也恢复正常。

回头看，这次问题其实都不算特别难，但它们连在一起时，确实很容易让人烦躁。尤其是你以为“这个应该修好了”，结果下一秒又冒出新的报错。不过换个角度想，这种排查过程反而更能帮助自己理解一个项目到底是怎么跑起来的。JDK决定你能不能编译，配置决定你能不能启动，外部资源决定你能不能连接，安全组件决定你能不能真正完成业务动作。很多时候，所谓“项目跑不起来”，并不是某一个点的问题，而是整个运行链路里有几个小环节同时没对齐。如果你也在做老项目迁移或者环境重搭，建议优先检查三件事：JDK版本、配置键是否标准、依赖升级后有没有额外的安全约束。这三类问题，出现概率真的比想象中高得多。

最后附上一张成功的结果图把，捣鼓一天终于可以继续跟黑马的课程了