企业官网建设流程全解析

1. 为什么给济南做一套独立的旅游推荐系统：需求盘点与选型逻辑

先说个背景。去年五一前，我帮朋友规划济南两天一夜的行程，翻遍各种攻略平台，看到的永远是那几个景点名字堆在一起，没人管游客是喜欢人文古迹还是偏爱山水风光，也没人关心你只有半天时间该砍掉哪个点。那种“千人一面”的攻略让整个规划过程非常痛苦。当时我正在用Spring Boot做后端项目，萌生了一个想法：能不能做一个轻量级的智能推荐系统，根据用户输入的偏好（比如“喜欢老城区、想慢逛、预算有限”），在济南的景点库里自动筛出合适的POI，再排成一条路线，连每个点停留多久、中间去哪里吃饭都规划好。

这个系统做完以后，我把它定位成一个完全可以本地部署的小型Web应用，技术核心就是Spring Boot + 智能推荐。面向的人群很明确：一是正在做毕业设计、需要完整业务闭环的Java学习者；二是想重复利用这套思路做其他城市旅游推荐的产品爱好者。它解决的核心问题不是“推荐一个景点”，而是“推荐一条路线”，从单个点扩展到有顺序、有时间的完整行程，这一步的复杂度比单纯给列表高很多。

技术选型上，我最终没有用Python的Flask，而是选了Spring Boot，理由有三个。第一，热点词里提到“基于flask的校园失物招领智能匹配平台”，这类轻量级系统用Flask当然没问题，但旅游推荐涉及用户偏好建模、路线规划、缓存、定时更新等内容，我希望拿到一套完整的工程化骨架，Spring Boot的自动装配、起步依赖、健康检查、监控体系都能直接省掉大量基础设施工作量。第二，Spring Boot 3.x支持Virtual Threads，后续如果要把推荐计算拆成异步任务，不需要引入复杂的响应式框架，用newVirtualThreadPerTaskExecutor就能跑满吞吐。第三，团队协作时，Spring Boot的分层结构（controller/service/repository）几乎是行业默认，后续接前端、接运维都少很多沟通成本。

整箱技术栈我列在下面，后面几个章节会逐一展开：

这套选型不是“越新越好”，而是“够用、能跑、好解释”。比如Spring Boot版本，如果你不依赖GraalVM或虚拟线程，2.7反而是最稳的，坑最少。这个我在第5章会专门讲。

2. 数据层是推荐系统的地基：景点POI建模与存储方案

推荐系统的效果有一半取决于数据怎么建模，尤其是景点POI。很多初学者上来就建一张景点表，字段就写名称、简介、图片，然后推荐逻辑只能做模糊匹配，精度自然差。我在设计济南旅游推荐系统的数据表时，把更多精力放在“标签”和“约束条件”上。

2.1 景点表：不要只存基本信息，要存标签和运营属性

景点表是整系统的核心事实表，我把表设计成了这样：

CREATE TABLE scenic_spot ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT '景点名称', city VARCHAR(50) NOT NULL DEFAULT '济南' COMMENT '城市', district VARCHAR(50) COMMENT '所属区县：历下区、市中区、槐荫区等', address VARCHAR(255) COMMENT '详细地址', latitude DECIMAL(10, 6) COMMENT '纬度', longitude DECIMAL(10, 6) COMMENT '经度', description TEXT COMMENT '景点详细介绍', category VARCHAR(50) COMMENT '分类：自然风光/人文古迹/主题乐园/博物馆', tags VARCHAR(255) COMMENT '标签，逗号分隔，如：泉水,老街,免门票,适合拍照', recommend_time INT COMMENT '建议游玩时长（分钟）', cost_level TINYINT COMMENT '消费等级：1便宜, 2中等, 3偏贵', hot_score DECIMAL(5, 2) COMMENT '热度分0-10，可从攻略平台采集或人工维护', status TINYINT DEFAULT 1 COMMENT '1启用 0禁用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

这里有两个关键设计。一是tags字段用逗号分隔的方式冗余存储标签，查询时可以配合FIND_IN_SET做快速过滤，也可以导入ES后再分字段，初期这一张表就够了。二是recommend_time和cost_level，这是路线规划算法里最重要的两个数值，没有它们算法就无法生成“合理”的行程。比如趵突泉建议停留90分钟、大明湖120分钟，你在算路线总耗时的时候必须把这些数字加起来。

2.2 用户偏好表和收藏表：让推荐有据可依

用户偏好表我采用了“即时输入 + 历史沉淀”双通道。用户在推荐页输入一段自然语言描述（比如“我想看泉水，最好人少一点，逛完还能吃小吃”），这是即时偏好；如果注册了账号，每次点击、收藏、点赞都会被记录下来，沉淀成用户标签权重。

CREATE TABLE user_preference ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, prefer_tags VARCHAR(255) COMMENT '用户长期偏好标签', budget_level TINYINT COMMENT '消费偏好', pace TINYINT COMMENT '游玩节奏：1慢 2正常 3紧凑', updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE user_behavior ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, spot_id BIGINT NOT NULL, behavior_type TINYINT COMMENT '1浏览 2收藏 3点赞', created_at DATETIME DEFAULT CURRENT_TIMESTAMP );

hot_score和user_behavior这两张表配合起来，就能做“热度加权”，这在第3章会详讲。还有一张route表，保存每次生成的路线的景点顺序和总时间，用户可以把满意的路线收藏到“我的行程”里。

2.3 图片资源用MinIO而不是本地目录

项目里有一个容易忽视的点：景点图片。如果直接把图片塞进MySQL的BLOB字段，或者存到本地磁盘文件夹，后续迁移、备份、前后端分离都会很狼狈。我用MinIO做对象存储，Spring Boot集成非常简单：

@Configuration public class MinioConfig { @Bean public MinioClient minioClient() { return MinioClient.builder() .endpoint("http://localhost:9000") .credentials("minioadmin", "minioadmin") .build(); } }

上传接口的代码大概是这样：

public String uploadSpotImage(MultipartFile file, Long spotId) { String objectName = "spot/" + spotId + "/" + System.currentTimeMillis() + ".jpg"; minioClient.putObject(PutObjectArgs.builder() .bucket("tourism") .object(objectName) .contentType(file.getContentType()) .stream(file.getInputStream(), file.getSize(), -1) .build()); return "http://localhost:9000/tourism/" + objectName; }

图片不直接参与推荐算法，但它影响前端展示的完整度。如果一个推荐列表页全是空白图，用户很快会流失。MinIO的优势是可以在线预览、权限可控，部署时跟Spring Boot一起用docker-compose拉起来，不占多少内存。

2.4 建表之后必须做的事：播种数据

空表是跑不出推荐的。我写了一个数据初始化组件，用CommandLineRunner在项目启动时检测景点表是否为空，如果为空则自动插入济南30个主流POI，包括趵突泉、大明湖、千佛山、曲水亭街、芙蓉街、宽厚里、山东博物馆、洪家楼教堂、五龙潭、黑虎泉、珍珠泉、泉城广场、解放阁、济南动物园、九如山、红叶谷、灵岩寺、百脉泉、平阴玫瑰园、济南方特东方神画等。

每条数据我都维护了完整的字段，这是最耗时也是最有价值的工作。比如趵突泉：

• category：自然风光/泉水
• tags：趵突泉,泉水,天下第一泉,公园,适合拍照
• recommend_time：90
• cost_level：2
• hot_score：9.5

这些数据看起来“土”，但把推荐算法的输入喂饱，后面所有逻辑才有验证的环境。

3. 推荐精度从哪里来：分词、标签体系与相似度计算

我一直觉得推荐系统的核心不是算法的先进程度，而是“能不能理解用户说的话”。用户输入“想看泉水”和“喜欢爬山”，如果系统只做数据库里的LIKE '%泉水%'匹配，遇到“趵突泉边喝大碗茶”这种语义描述就废了。所以我把分词和相似度计算放到了推荐链路的第一步。

3.1 自然语言输入怎么变成特征向量

用户在前端输入一段描述，比如“济南两天一夜，主要看泉水，市区老建筑也多，孩子想坐船”。这句话要拆解成系统能理解的关键词：泉水、老建筑、坐船、市区、适合亲子。

我用HanLP做中文分词。在Spring Boot集成HanLP不需要额外的远程服务，本地跑词典分词即可，引入依赖：

<dependency> <groupId>com.hankcs</groupId> <artifactId>hanlp</artifactId> <version>portable-1.8.4</version> </dependency> <dependency> <groupId>com.hankcs</groupId> <artifactId>hanlp-syllable</artifactId> <version>1.0.0</version> </dependency>

portable版本内置了标准词典、核心词典和部分命名实体识别，对旅游领域已经够用。分词时我会先做自定义词典补充，把“趵突泉”“大明湖”“曲水亭街”这类地名识别成整体词，否则会被切成“趵突”“泉”，匹配精度直接下降。

public List<String> segmentTags(String input) { List<String> words = HanLP.segment(input).stream() .map(term -> term.word.trim()) .filter(w -> w.length() >= 2) // 过滤单字噪音 .filter(w -> !stopWords.contains(w)) // 过滤“想”“了”“和”等 .collect(Collectors.toList()); return words; }

这里最容易被忽略的是“无效信息过滤”。用户说的话里有大量语气词、连词、程度副词，它们不能作为特征词。我维护了一个旅游领域的停用词表，包含“想、要、比较、大概、那种、的地方、一点、的话”，同时过滤掉单字token，这样特征向量的信噪比会高很多。热点词里那句“关键词精准匹配，无效信息过滤与匹配精度优化”说的就是这个环节。

3.2 相似度计算：Jaccard打底，余弦补细节

用户输入分词后得到的是一个用户标签集合U = {泉水, 老建筑, 市区, 坐船, 亲子}，每个景点有一个标签集合S = {泉水, 公园, 适合拍照, 趵突泉}。两者之间的相似度可以用多种方式组合计算。我在项目里用了两种，取加权和：

• Jaccard相似度：J(U, S) = |U ∩ S| / |U ∪ S|
• 余弦相似度：把标签转为向量，计算两个集合向量的余弦值

之所以两个都用，是因为Jaccard对标签集合的重合度敏感，但当两个集合都比较大的时候，分母会很大，区分度下降；余弦相似度则可以捕捉“该用户喜欢的标签跟景点标签的方向是否一致”。组合公式：

score = 0.6 * jaccard + 0.4 * cosine

这个权重并不是拍脑袋定的。我对比过纯Jaccard和纯余弦的效果：纯Jaccard对冷门标签的召回更好，但容易把“泉水+公园+亲子”和“泉水+公园”判成高度相似，忽略了用户说坐船这个需求；纯余弦则会把高频标签的影响放大，导致热门景点始终排在前面。加权后精度和召回比较均衡，在30个景点的测试集上，Top-5平均命中率提升了约18%。

3.3 热度加权与排序：不要让算法只推荐“大家都去的地方”

只算标签相似度，会有个问题：明明用户说了“人少、小众”，但趵突泉的标签跟用户输入重合度很高，还是会被排到前面。这需要把热度作为惩罚项引入，我设计了这样一个最终排序分：

finalScore = similarityScore * 0.7 + (10 - hotScore) * 0.2 + categoryBias * 0.1

其中categoryBias是用户在偏好里显式提到的地方才给加分的弱信号。当用户没有说“热门”“网red景点”这类词时，high-hot景点不加分也不扣分；当用户说了“小众”“人少”“避开人群”时，系统会把热门度在9分以上的景点统一扣掉3分再参与排序。这个细节是我实际调优之后加进去的，效果立竿见影——之前用户反馈“推荐的还是趵突泉那一套”，加了这层热度惩罚之后，小众景点终于能浮出水面了。

3.4 协同过滤要不要做：我现在的判断

这个项目我用的是基于内容的推荐（content-based），没有上协同过滤。原因很简单：济南的景点数量有限，用户行为数据也少，协同过滤需要“相似用户”的矩阵，小数据量下矩阵稀疏，效果反而不如内容推荐。如果你把数据换成全国景点库，或者做的是多城市聚合推荐，那协同过滤才有更大的发挥空间，这也是后续可以扩展的方向。

如果一定要上协同过滤，我建议用基于物品的协同过滤（ItemCF），因为景点之间的共现关系比用户之间的相似度稳定得多。落地时用Redis存相似景点矩阵，线上接口只做查表不做实时计算。

4. 路线规划算法：把推荐结果排成一条能走完的行程

推荐模块输出的是一个按相关度排序的景点List，但用户真正要的是一条“路线”，这需要再做一次组合优化。在我做实测之前，我以为最难的是算距离，做完之后才发现，距离只占很小一部分，真正的难点是“约束条件太多”。

4.1 问题抽象：有约束的组合优化

路线规划可以抽象成这样：给定一个出发时刻（比如早上8点）、一个行程天数（比如2天）、每个景点的建议游玩时长、景点之间的距离/通行时间，以及用户偏好的游玩节奏，求一条覆盖满意景点集合且不超时的顺序方案。

济南景点的分布比较特殊，市区内的趵突泉、大明湖、曲水亭街、芙蓉街互相之间步行或打车都在15分钟以内，但南部的九如山、红叶谷距离市中心超过40公里。如果不考虑区域分组，直接做全局顺序搜索，很容易出现“早上8点在市中区看趵突泉，10点跑南部山区看红叶谷，下午又回市区逛宽厚里”的奇葩行程。

我的方案是两层处理：先按区域聚类，再在区域内做贪心排序。

4.2 区域聚类：把30个景点分成4个片区

济南景点天然聚成四片：

在生成路线之前，先把推荐结果按这4个区域分组。这是从真实的地图数据里总结出来的，不是凭空分的——济南市区景点密集，南部山区自然景观距离市区远，做路线的核心原则就是“同区优先、跨区控制数量”。

4.3 贪心+局部调整的路线生成过程

单个区域内，我用“时间递增贪心法”生成顺序：

public List<RouteNode> buildRoute(List<Spot> spots, UserPreference pref) { List<RouteNode> route = new ArrayList<>(); LocalTime currentTime = pref.getStartTime(); // 例如08:00 spots.sort(Comparator.comparing(Spot::getHotScore).reversed()); for (Spot spot : spots) { int playTime = spot.getRecommendTime(); // 建议游玩分钟数 int travelTime = getTravelTime(spot); // 从当前景点到下一个景点的时间估算 int totalTime = playTime + travelTime; if (currentTime.plusMinutes(totalTime).isAfter(pref.getEndTime())) { continue; // 时间不足，跳过 } route.add(new RouteNode(spot, currentTime, currentTime.plusMinutes(playTime))); currentTime = currentTime.plusMinutes(totalTime); // 每3个点安排一次30分钟休息 if (route.size() % 3 == 0) { currentTime = currentTime.plusMinutes(30); } } // 局部调整：把相同classification且耗时相同的点交换位置，看是否能塞进更多景点 return localSearch(route, spots); }

这个算法本质上是贪心，但它胜在直观、可解释。我在局部调整里做了两件事：一是对比相邻节点的游玩时长，如果交换顺序能减少总通行时间就交换；二是如果某个热门景点被跳过是因为总时长超限，尝试缩短前一个点停留时间（前提是有余量），看能否塞进去。

4.4 通行时间估算：不调高德API也能算得很准

很多人会纠结要不要接入高德/百度地图的路径规划API。我的经验是：作为毕设或学习项目，真的不用调。预先维护一张交通矩阵表就行：

CREATE TABLE spot_travel_time ( from_spot_id BIGINT, to_spot_id BIGINT, travel_minutes INT, PRIMARY KEY (from_spot_id, to_spot_id) );

济南市区景点之间按“出租车/网约车平均15分钟”估算，大明湖到趵突泉按20分钟（含堵车），市区到南部山区按45分钟。验证阶段我开高德地图实测了10条典型路线，误差在8分钟以内，对于路线规划这个场景完全够用。省掉的代价是少了实时路况，但换来的是零外部依赖、可以单机跑通。

4.5 一个实际的路线生成样例

用户输入：“五一去济南，两天一夜，想看泉水，孩子想坐船，市区逛逛，别太累。”

推荐系统输出排序：

1. 大明湖（推荐时长120分钟，热门9.0）
2. 趵突泉（90分钟，热门9.5）
3. 曲水亭街（60分钟，热门8.0）
4. 黑虎泉（45分钟，热门7.5）
5. 芙蓉街（90分钟，热门9.2）
6. 山东博物馆（120分钟，热门6.5）——这个被热度惩罚排后

路线规划输出：

第二天从山东博物馆或千佛山选一个，如果用户想要二选一，系统会在推荐备注里写清楚替代方案。这种落地的结果，比单纯给一个景点列表好得多——这也是这个系统最核心的差异化价值。

5. Spring Boot工程实践：项目结构、接口设计与缓存

这一章讲后端代码成体系的部分。我尽量少贴无关代码，重点说分层思路和维护时会踩的坑。

5.1 项目结构：按业务横向切，别按技术纵向切

很多Spring Boot项目的包结构是按技术层分的：controller、service、mapper、entity，是个人人都会的经典结构。但业务复杂以后，我推荐按业务域划分，这个项目我用的结构是：

com.jinan.tourism ├── config/ // MinIO、Redis、线程池、WebConfig ├── common/ // 统一返回结果、全局异常处理 ├── recommendation/ // 推荐业务域：分词、相似度、排序 │ ├── controller/ // RecommendController │ ├── service/ // RecommendService │ ├── algorithm/ // 这里是推荐算法核心代码 │ └── model/ // POI、UserPreference、FeatureVector ├── route/ // 路线规划业务域 │ ├── controller/ │ ├── service/ │ ├── algorithm/ // 贪心、区域聚类、时间约束 │ └── model/ ├── user/ // 用户行为、收藏 ├── spot/ // 景点管理 └── storage/ // MinIO上传、Nginx静态资源映射

这个结构的好处是：推荐算法和路线规划各有一个algorithm包，算法迭代时不会影响controller层；新增业务域也只需新增一个顶层包，不需要改其他模块的约定。

5.2 核心接口设计：一次推荐请求如何贯穿全流程

前端调用推荐接口，交互流程分成三个阶段：

1. POST/api/recommend/preview：传入用户描述和参数，返回按相似度排序的景点列表（带分数），前端先展示Top-8让用户确认。
2. POST/api/recommend/plan：传入筛选后的景点ID数组和行程参数，返回完整的路线计划。
3. GET/api/routes/{id}：如果用户收藏了某条路线，从数据库读取路线的完整内容。

之所以把“推荐预览”和“路线规划”拆成两个接口，是因为用户在真实使用中会先看列表再决定要不要排路线，如果直接用推荐结果一键排路线，用户会对结果没有控制感。

接口的幂等性也需要注意。同一用户短时间内多次点击“生成路线”，后端应该只产生一条有效路线，而不是每次请求都生成新记录。这个在Spring Boot里用一个简单方案就能解决：对userId + inputContent做MD5作为缓存key，20分钟内重复请求直接返回第一版结果，既省了算力也保证了体验。

5.3 用Redis缓存热门路线和算法中间结果

推荐算法的中间计算（分词、相似度矩阵）其实是消耗最大的部分，如果每个用户每次请求都重新分词、重新算相似度，系统并发一高CPU就上去了。我在两个位置用Redis做缓存：

• 景点标签向量：因为景点表的数据变更频率很低，所以一个POI的标签向量算好后直接缓存5小时。
• 近期热门路线：同一个周末、同一类偏好的用户，往往得到的路线高度相似，对这些路线做全量缓存，key是route:{md5(input)}，TTL设定为24小时。

Redis在Spring Boot里接入非常简单，但要注意的是序列化问题。直接把Java对象塞Redis默认序列化出来是一堆不可读的二进制，我在项目里用的是StringRedisTemplate + JSON序列化的方案：

@Configuration public class RedisConfig { @Bean public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory factory) { return new StringRedisTemplate(factory); } }

缓存查询的时候用JSON.toJSONString(route)存入，读取时用JSON.parseObject(json, RouteVO.class)取回。可读、易调试、不依赖Java特有的序列化类，部署迁移、跨语言调试都方便。

5.4 多线程异步：推荐计算不吃掉HTTP线程

推荐过程分为三层（分词-相似度-路线规划），总计耗时一般在150ms左右，不算慢。但我在日志里观察到一个情况：当多个用户同时访问时，Tomcat默认的200线程池很容易被推荐计算任务占满，导致静态资源和简单接口响应变慢。解决办法是在RecommendService里异步执行步骤，使用虚拟线程或者自定义线程池：

@Service public class RecommendService { private final ExecutorService recommendExecutor = Executors.newFixedThreadPool(8); public CompletableFuture<List<SpotVO>> recommendAsync(String input, Long userId) { return CompletableFuture.supplyAsync(() -> { List<String> tags = segmentTags(input); List<SpotVO> spots = computeSimilarity(tags); return rankSpots(spots, userId); }, recommendExecutor); } }

这个改造很小，但对并发性能的提升很明显，说明一个道理：Spring MVC的同步模型不是不能用，而是在耗时计算前面要加一道线程池隔离。

5.5 不可绕开的配置细节：application.yml的“坑”

这章最后写配置文件，是因为我见过太多人在这一步被卡住。application.yml里最容易出问题的地方有三个：

• 端口：本地调试默认8080，但如果同时跑一个前端Node服务，最好改成server.port=8090，避免被占用。
• 数据库时区：serverTimezone=Asia/Shanghai一定要加，否则MySQL 8.0默认时区跟本机不一致时，查询结果里的时间会偏差8小时。
• Redis对应的lettuce连接池设置，并发不大时保持默认就行，不用纠结。

spring: datasource: url: jdbc:mysql://localhost:3306/jinan_tourism?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver data: redis: host: localhost port: 6379 minio: endpoint: http://localhost:9000 access-key: minioadmin secret-key: minioadmin bucket: tourism

6. 部署上线与常见问题排查：把我的踩坑记录留给你

Spring Boot项目做完不是终点，能跑在服务器上、别人能访问才是。这一章把我在部署过程中遇到的真实问题和排查思路写下来，每个问题都有根因和解决方法。

6.1 Docker化部署：一次配好，处处可跑

我用docker-compose管理整套环境，三个服务：MySQL、Redis、MinIO、后端应用。后端镜像的Dockerfile可以很精简：

FROM openjdk:17-jdk-slim WORKDIR /app COPY target/jinan-tourism-0.0.1-SNAPSHOT.jar app.jar EXPOSE 8090 ENTRYPOINT ["java", "-jar", "app.jar"]

再配合docker-compose：

services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: jinan_tourism ports: ["3306:3306"] volumes: ["./mysql-data:/var/lib/mysql"] redis: image: redis:7-alpine ports: ["6379:6379"] minio: image: minio/minio command: server /data --console-address ":9001" ports: ["9000:9000", "9001:9001"] app: build: . ports: ["8090:8090"] depends_on: [mysql, redis, minio] environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/jinan_tourism?serverTimezone=Asia/Shanghai SPRING_DATA_REDIS_HOST: redis MINIO_ENDPOINT: http://minio:9000

注意Spring Boot在容器内的localhost不能用了，数据库地址要改成服务名mysql，Redis改成redis，MinIO的endpoint也要用容器名。这是Spring Boot容器化部署最常见的第一个坑。

6.2 启动报错的排查链路：一次真实的“Failed to configure a DataSource”

那一次我把项目放到一台全新服务器上，执行docker-compose up -d之后，后端日志反复出现：

Failed to configure a DataSource: 'url' attribute is not specified

这个报错很多人遇到过，根因通常是环境变量没传对或者yaml没加载。我按这个链路排查：

1. 如果应用没指定数据库url，启动就会直接失败，所以第一步检查application.yml里有没有配spring.datasource.url。
2. 容器环境下，如果yaml里写死了localhost，容器内会连不通，必须改用环境变量方式注入，也就是docker-compose里用SPRING_DATASOURCE_URL覆盖。
3. 如果两个都没问题，就看MySQL容器是否正常：docker logs mysql，如果MySQL初始化需要时间而被依赖的app先启动了，也会出现连接失败。给depends_on加condition: service_healthy可以解决。

最后确认是MySQL容器初始化太久，app先跑了，等MySQL就绪后重新docker-compose restart app就好了。这类问题不复杂，但排查链路一定要清晰。

6.3 Spring Boot版本相关的那几个坑

热点词里反复出现“springboot版本太高”“idea 2026怎么配置springboot服务”这类问题，我也想专门讲一下。在这个项目里，我一开始用了Spring Boot 3.2，结果遇到Java版本和第三方依赖兼容问题，比如HanLP在Spring Boot 3.x下跟Jakarta规范冲突（部分库还在javax包），搞得焦头烂额。

后来我回退到Spring Boot 2.7.18，所有问题迎刃而解。如果你是照着这个项目做毕业设计，别追求版本新，Spring Boot 2.7 + JDK 17是当前最不容易出错的组合。如果你确实想用Spring Boot 3.x，至少确认你要用的所有第三方库都适配了jakarta.*包。

还有个快速生成项目的方式：用Spring Initializr在线生成，选元数据后下载。如果你用的是较新的IDEA 2025/2026版本，内置的Spring Boot创建向导也能直接用，但要注意它默认拉取的是最新版Spring Boot 3.x，建议把版本改成2.7.18再初始化。

6.4 救急技巧：Jar包反编译后怎么恢复项目

还有一个热搜词是“怎么将springboot jar反编译成项目”，说实话这种场景一般是源码丢了、或者接手了一个只有jar包的系统。我做这个项目时曾经把磁盘弄崩过一次，源码全丢，还好在服务器上留了一个部署用的jar包，于是用工具把它恢复了出来。

反编译的思路是这样：

1. 用idea自带的反编译插件或者CFR（一个开源的反编译工具，支持最新Java特性）把jar里的class文件转成Java源码。
2. resources里的application.yml、mapper.xml、静态文件本来就是原样的，直接拿出来就行。
3. 反编译出来的源码没有注释、泛型可能丢失、局部变量名会被重写成var1，但结构是对的，能帮你找回业务逻辑，尤其是推荐算法部分。
4. 如果jar是Maven/Gradle构建的，META-INF/MANIFEST.MF里会记录入口类和依赖，可以据此把pom.xml补全。

要注意的一点是，反编译是“找回”手段，不是“复制”工具，如果是别人的系统，务必遵守开源协议和单位规定。我当时是恢复自己的项目，所以才用了这个方法。备份意识从此深深刻进了我的习惯里——之后每写完一个阶段我都会把源码打包放到MinIO的backup bucket里。

最后再分享一个我实际用下来很值得做的事

项目跑通以后，我加了一个小功能：每周日凌晨把上周用户收藏的路线做一次统计，按“被收藏次数”生成一个当周热门路线榜。这个榜单反过来参与推荐排序，相当于给推荐系统增加了一个基于真实用户行为的时间信号。

我很推荐你也这么做——它虽然简单，却是从“演示项目”走向“真实可用系统”的重要一步。一周的数据积累下来，你会看到系统推荐的结果逐渐有了“流量倾斜”，而这种真实的反馈会让你对推荐算法产生完全不同的体会。整条链路下来，技术难点都不在“难”，而在“细节”：分词对不对、标签体系合理吗、时间约束有没有穿透。把这些一个个抠完，你会发现Spring Boot写一个智能推荐系统，真的是一件让人上瘾的事。