企业官网建设流程全解析

最近又到了毕业设计的节点，陆陆续续有不少人私信问我“推荐系统方向的题目怎么做”。今年被问得比较多、也是我自己带过几个学弟学妹后觉得挺值得复盘的一个项目，就是这一类“基于Java+SSM+Flask的大湾区旅游推荐系统”。名字很长，但实际上拆开看就是一个典型的“传统业务管理端 + 轻量算法推荐端”混合架构项目，既有Java后端该有的增删改查和权限管理，又有Python生态里做推荐服务最舒服的Flask接口层，两头都能学到东西，也算是对“Java和Python怎么配合做事”的一个很真实的演练。

这篇文章我不打算讲太虚的东西，直接把整个项目从需求、表设计、算法、部署到排坑，按我自己实操的路径捋一遍。无论你是拿这套源码做毕设、准备答辩，还是想从纯Java项目往推荐系统方向过渡，都可以把这篇文章当成一份带着踩坑记录的思路参考。

1. 项目定位与需求拆解

1.1 这到底是个什么系统

先别被那一长串标题吓到。这个项目本质上是围绕“大湾区旅游”这个主题做的内容管理与个性化推荐一体化平台。目标用户分两类：一类是游客，也就是前台普通用户；另一类是运营方，也就是后台管理员。

游客端做的事情很朴素：

• 浏览大湾区范围内的景点信息，比如广州塔、长隆、珠海长隆海洋王国、深圳世界之窗、澳门大三巴这类核心地标；
• 看别人分享的旅游攻略和路线；
• 按“必去景点”“美食推荐”等栏目筛选内容；
• 系统根据你浏览过的内容，给你推荐你可能会感兴趣的景点和攻略。

管理端做的事情也很常规：

• 管理景点、攻略、线路、美食的数据维护；
• 审核用户发布的攻略；
• 查看用户行为记录和推荐效果统计。

从技术角度来看，这个系统的核心就是两件事：内容管理和推荐逻辑。内容管理是老生常谈的SSM框架三板斧，推荐逻辑则需要单独的服务来处理。用Java+SSM把业务规规矩矩写清楚，用Flask轻巧地把推荐计算承接起来，互相之间通过HTTP接口通信，是这类题目非常经典且合理的分工。

1.2 需求背后真正考察的能力点

做毕设选题的时候，很多人的第一反应是“这个题好像不难，就是SSM加个推荐”，真做起来才知道坑在哪。这个项目表面上是做一个网站，实际上在考察你四个方面：

第一，对业务数据的建模能力。旅游推荐系统不是简单地存一张景点表就完了，你要考虑景点、地区、标签、评分、攻略、线路、美食这些对象之间怎么关联，怎么设计字段才能让推荐算法有数据可用。

第二，混合语言协作的开发思维。到底哪些功能放Java端，哪些放Flask端，不是拍脑袋决定的，而是要根据业务特性来划分。管理系统的权限拦截、事务控制本来就是SSM的强项；相似度计算、排序输出这类逻辑放Python里写起来明显省力。能讲清楚这个划分依据，答辩时就是加分项。

第三，推荐算法的落地能力。学校课程里讲协同过滤、内容推荐，都是拿现成的库跑一个离线的准确率；但在这个项目里你要自己从数据库里取用户行为，算相似度，再把结果包装成接口返回给前端。这中间的编码细节比算法公式本身更考验人。

第四，系统的部署与调试能力。两个后端服务，一个跑在Tomcat上，一个跑在Python解释器里，怎么让它们连通，怎么处理跨域，怎么保证数据一致，这些都是实际项目里跑不掉的环节。

1.3 这套架构的适用场景

说句实在话，这个项目的架构设计思路并不仅限于旅游领域。你把“大湾区旅游”换成“校园二手物品”“剧本杀门店”“宠物领养”，业务逻辑和推荐模式是完全可以平移的。“基于区域内容 + 用户行为 + 智能推荐”的套路，在很多本地生活或内容分发类项目里都成立。所以你把这个项目吃透了，后面换题目也只是换数据，换汤不换药。

2. 技术选型解析：为什么是Java+SSM和Flask各管一头

2.1 SSM这边管什么

SSM是Spring+SpringMVC+MyBatis的组合。在这个项目里，它承担的是主业务服务的角色，也就是系统的“主动脉”。

用户管理、管理员登录、景点的增删改查、攻略的发布与审核、收藏与评论这些操作，全部走SSM这套。Spring负责把各个对象之间的依赖关系管起来，Controller层做参数接收和返回结果包装，Service层写业务规则，Mapper层通过MyBatis把SQL语句和Java对象做映射。这套模式你可能在课设里已经写过很多遍了，但它依然是企业级Java应用最经典的骨架，面试的时候也是高频考点。

选择SSM而不是Spring Boot，可能有人会觉得老气，但对于毕设这种场景来说它有自己的优势：结构分层极其清楚，每个类该干什么一眼就能看出来，写论文的时候模块划分也好写。而且本地跑起来占用资源小，Tomcat一启动就能访问，不需要搞复杂的自动配置。当然，你如果对Spring Boot更熟，后台端完全可以平移过去，不影响Flask推荐服务这部分的设计。

用MyBatis操作数据库的时候，我习惯把SQL写在XML里而不是注解里。理由很简单：这个项目里推荐系统要做的查询都比较特殊，比如要根据用户偏好标签查景点、要按热度排序、要联表查用户收藏记录，这些都是动态SQL的重灾区。XML里可以灵活拼条件，注解里写这种逻辑能把人逼疯。这也是我在实际调试中一个很重要的体会：能用XML就别硬塞注解。

2.2 Flask这边管什么

Flask在整个系统里的角色是推荐引擎的独立服务。它不直接操作数据库业务表，而是通过SSM后端暴露的HTTP接口获取数据，或者直接连同一个MySQL库读取需要的数据。

我比较推荐的做法是让Flask直接读取数据库中的用户行为表和内容表，这样做推荐计算的时候可以一次性查出所有需要的数据，减少和Java服务的HTTP通信次数。Flask的轻量体现在它不需要繁重的配置，写几个路由、算完推荐结果直接返回JSON，这对推荐服务来说再合适不过了。

Flask里实现推荐逻辑的核心思路其实不复杂，就是“算相似度”。具体来说，系统会根据用户浏览、收藏和搜索的行为，提取出用户的偏好关键词，然后和大湾区各个景点的标签做匹配。比如你经常看“海滨”“亲子”“美食”这几个标签的内容，系统就会综合计算景点标签和你偏好之间的相似度，把得分最高的几个景点推荐给你。这个计算过程不需要任何第三方机器学习库，用Python的字典、列表和集合运算就能实现，但效果比拍脑袋随机推荐不知道好到哪里去。

2.3 两个服务之间的通信和接口约定

Java端和Flask端不能各自为政，它们之间必须有明确的“约定”。这个约定就是RESTful接口。

我设计的交互方式是这样的：推荐服务启动后，Flask端提供几个核心接口，比如“获取用户个性化推荐结果”“获取热门景点TopN”“获取相似景点列表”，返回的数据格式统一为JSON。前端页面在展示推荐位的时候，直接向Flask发请求拿到推荐结果并渲染；需要做增删改查操作的时候，还是走SSM的接口。这样职责上分得很干净，调试的时候也容易定位问题到底是出在业务端还是推荐端。

有一个细节值得注意：两个服务如果部署在同一台机器上，端口要避开。SSM通常跑在8080端口，Flask服务我会单独指定在5000端口。前端做跨域请求时，再通过SSM的Controller层做一次转发，避免浏览器直接跨域调用Flask接口。这个跨域转发层我当时调试了很久才彻底搞定，后面排坑部分会详细讲。

3. 数据库设计：推荐系统能不能跑起来，一半看表结构

3.1 核心表清单和字段设计

数据库设计是这个项目里最值得花时间的部分之一。如果表建得不好，后面算法写得再漂亮也白搭。我把整个系统拆成了如下这些核心表，先给大家列一个框架：

• 用户表：用户ID、昵称、手机号、密码、头像、角色标识、注册时间、状态；
• 景点表：景点ID、名称、所属城市、详细地址、经纬度、封面图、简介、详细描述、热度值、标签、门票信息、开放时间、状态；
• 攻略表：攻略ID、标题、作者ID、所属景点ID、内容、封面图、发布时间、浏览量、点赞数、审核状态；
• 线路表：线路ID、线路名称、天数、途经景点ID列表、适合人群、线路简介、创建时间；
• 美食表：美食ID、名称、所属城市、店铺地址、推荐菜、人均消费、图片、标签、热度；
• 用户行为表：行为ID、用户ID、内容ID、内容类型、行为类型（浏览、收藏、搜索）、行为时间、行为权重；
• 收藏表：收藏ID、用户ID、内容ID、内容类型、收藏时间。

这里最需要详细解释的是用户行为表。传统的管理系统一般不会设计这么一张表，但推荐系统特别依赖它。每次用户查看一个景点详情，前端就通过一个埋点接口，把“哪个用户、在什么时间、看了哪个景点”记录到这张表里。搜索了什么关键词、收藏了哪个景点，也都会记录。这些行为数据是推荐算法唯一的信息来源，没有它，推荐系统就是无源之水。

行为权重这个字段为什么要单独设计出来？因为不同类型的用户行为代表不同的兴趣强度。搜索行为和浏览行为的权重低，但也代表用户感兴趣；收藏行为的权重高，直接表明用户对这个内容有强烈偏好。这个权重设计可以和另一条规则配合：系统计算用户标签偏好时，对所有历史行为的标签得分做加权求和，这样统计出的用户画像更准。

3.2 为什么景点表必须加标签字段

这是整个数据库设计里最核心的一个细节。很多旅游类项目表里就放名称、介绍这些基本信息，标签要么不做要么做成单独一张关联表。这个项目里我强烈建议直接用“逗号分隔的字符串标签”存进景点表的tag列，比如“海滨,亲子,美食,地标”。原因是推荐计算时，读取标签字符串后直接split成数组，就能和用户偏好集合做交集计算，效率非常高。

当然，正规的做法是内容表和标签做成多对多的关联表。但做毕设项目，在数据量并不大的前提下，用冗余字段换取代码简洁是完全可以接受的。你在论文里只要写清楚这一点，并说明数据量增大后的优化方向是什么，答辩老师不会为难你。

大湾区的景点覆盖的城市比较多，城市字段一定要规范化存。我建议直接存枚举值或标准名称，比如“广州”“深圳”“珠海”“佛山”“惠州”“东莞”“中山”“江门”“肇庆”“香港”“澳门”，不要存“广东广州”这种多余的前缀。后面要做“按城市筛选景点”功能时，SQL查询会干净很多。

3.3 热度值怎么算出来的

热度值是推荐系统冷启动阶段最重要的工具。新用户进来没有任何行为数据，推荐什么？总不能空着，这时候就靠热度值顶上。

热度值我建议用这样一个简化的公式来算：

热度值 = 基础分 + 浏览量0.1 + 收藏量0.5 + 攻略引用次数*1.0

比如一个景点初始基础分是100，浏览量10000，收藏量800，被攻略引用了30次，那它的热度值就是100 + 100000.1 + 8000.5 + 30*1.0 = 100 + 1000 + 400 + 30 = 1530。

这个热度值在后台每次用户访问景点详情时更新一次，不需要实时计算。推荐系统在冷启动阶段，就按照热度值从高到低把景点铺给新用户。这样既保证了推荐内容的底线质量，也避免了新用户面对空页面的尴尬。

4. 推荐算法实现：从推荐思路到Flask接口

4.1 基于标签偏好的相似度推荐

这个项目最核心的算法逻辑，就是“基于内容的推荐”，本质上是计算用户偏好标签和景点标签的匹配程度。我用Python在Flask里实现的一套思路，代码逻辑非常直观。

用户画像构建的逻辑如下：把用户历史行为数据全部捞出来，行为类型映射到权重，浏览记0.5、搜索记0.8、收藏记1.0。每个行为都会关联到一个景点，景点对应一组标签。把所有行为权重的标签得分累加起来，就得到一个“用户标签得分字典”，取得分最高的几个标签作为用户偏好标签集合。

然后计算景点和用户的匹配度时，遍历所有景点，取出景点标签集合，和用户偏好标签集合做交集。交集的标签越多，匹配度得分越高。

举一个实际的例子，用户历史行为里面点了两个景点：一个是“广州塔”，标签是“地标,夜景,城市观光”；另一个是“珠海长隆海洋王国”，标签是“亲子,乐园,海洋”。那么用户的偏好标签集合就是“地标,夜景,城市观光,亲子,乐园,海洋”的综合加权。如果候选景点是“深圳欢乐谷”，标签是“乐园,刺激,亲子”，它的标签和用户偏好的交集有“乐园”和“亲子”两个，匹配度就很高，可以进入推荐列表。

这套算法没有用到任何机器学习库，纯Python字典和集合运算就能完成，而且解释起来逻辑性很强，答辩时非常好讲。你也可以在此基础上加入一点点优化，比如两个景点之间通过共同标签数量计算相似度，把“用户看过A景点”转化为“推荐与A景点相似的其他景点”，就成为了一种简单的协同过滤思路。这两种思路结合起来，整个系统的推荐逻辑就更丰满了。

4.2 Flask服务接口怎么设计

Flask服务不是一个给人看的网站，它是一堆纯JSON接口。我设计路由的时候遵循一个原则：按“资源”来定义URL，而不是按“功能”来定义。

几个核心接口如下：

• GET /api/recommend/<user_id>?top_n=10：获取指定用户的个性化推荐列表；
• GET /api/similar/<scenic_id>?top_n=5：获取指定景点的相似推荐；
• GET /api/hot?city=广州&top_n=10：获取热门景点列表，用于冷启动和兜底。

返回的JSON格式建议统一为这样：

{ "code": 200, "data": [ { "scenic_id": 1, "name": "广州塔", "city": "广州", "tags": ["地标", "夜景"], "score": 0.87 } ], "message": "success" }

每个推荐项除了基本信息外，一定要带一个score字段。这个score代表置信度或者匹配度，前端可以根据score的分布来决定是展示“热门推荐”还是“猜你喜欢”这类栏目标题。带score还有一个好处是方便调试——你看到推荐结果不理想时，可以很快定位是算法算低了还是数据本身缺失。

4.3 SQL查询和推荐数据准备

Flask端从MySQL取数时，我把关键查询都封装成独立的函数。有一个查询让我印象最深刻：查询用户所有行为并关联景点标签，这个逻辑用Python写需要双层循环，但在SQL层面应该是尽量做联表。一次查出行为记录和景点标签，Python里再做聚合，比数据库查询做十几次要高效得多。

推荐计算本身不需要框架，纯Python的列表推导配合字典分组就够用。如果你对数据结构的掌握比较熟，lambda表达式在这里也能用得很顺手。

数据量大到一定程度后，你也可以考虑用Redis做推荐结果的缓存，避免每次刷新页面都重新计算一遍。但在毕设演示阶段，数据量撑死几千条，直接算完全没压力。关于这一点说实话，我在带学弟做的时候就没让他上Redis，因为那是给自己找麻烦。答辩时提一句“后续可以引入缓存层提升性能”，这话说到位就够了。

5. 实操记录：从源码导入到系统跑通全流程

5.1 环境准备与项目导入

拿到源码后第一步是把环境对齐。我先说一下我这边稳定运行的环境版本，你自己照着配基本不会出问题：

• JDK版本：JDK 1.8，不要用太高版本，Java 17在某些老SSM项目里会因为模块访问限制出莫名其妙的错；
• Maven：3.6.3及以上，用于管理SSM工程的依赖；
• MySQL：5.7或8.0，注意8.0以上需要修改驱动配置；
• Tomcat：8.5或9.0，直接把war包丢进webapps目录启动；
• Python：3.8以上，Flask建议2.x版本；
• IDE：Java端用IDEA，Python端用PyCharm或VS Code都行。

导入Java工程后，首先要检查application.properties或db.properties里的数据库连接配置。这里有一个踩坑率极高的点：MySQL 8.0以上版本，驱动类要改成com.mysql.cj.jdbc.Driver，连接URL里必须加上时区参数，否则启动报错会让你怀疑人生。MySQL 5.7时代用的com.mysql.jdbc.Driver在8.0下已经废弃，不兼容。

5.2 数据库脚本初始化

源码包里一般会带一个database.sql或tour.sql，用Navicat或命令行执行前，我建议你先用文本编辑器打开这个SQL文件读一遍。主要确认两件事：第一，脚本里有没有反复DROP TABLE的操作，有的话数据会清空；第二，脚本里有没有插入测试账号和管理员账号，方便你启动后立即登录查看。

入库完成后，建议执行下面这条SQL看看各个表的数据量分布：

SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='tour_db';

景点表、用户表、行为表、攻略表的数据都在，说明数据初始化成功。如果发现行为表是空的，一定要补录几条测试行为数据，否则推荐系统一个结果都算不出来。这是最容易忽略但后果最严重的细节。

5.3 SSM后端启动与踩坑

把工程部署到Tomcat后，启动日志输出到“Connected to server”或者“Server startup”字样，访问http://localhost:8080/，能看到系统登录页或首页就说明Java端起来了。

启动过程中如果遇到端口被占用，可以在IDEA里直接把Tomcat的端口改掉，或者在命令行里杀掉占用进程。Windows下用netstat -ano | findstr 8080找到PID，然后taskkill /PID <pid> /F结束进程，这是最常用的排查手法。

SSM日志是我最依赖的调试工具，你在IDEA的Run控制台里会看到Log4j或Logback输出的SQL日志。打开MyBatis的SQL日志打印功能后，每个Mapper执行的具体SQL语句都能看到，参数不够、字段名对不上、查询结果和预期不一致，看日志基本都能定位。

5.4 Flask服务启动与联调

Python端单独在命令行里执行python app.py启动Flask服务。启动成功后，终端会显示Running on http://127.0.0.1:5000。

用浏览器直接访问http://127.0.0.1:5000/api/hot?top_n=5，如果返回一段JSON数据，说明推荐服务已就绪。这里要注意一点：Flask服务一定要先于前端页面测试前启动。如果只启动了Java端，你打开首页时所有推荐位都会解析失败，因为推荐接口没有数据返回。

联调时最常遇到的问题是前端页面请求Flask接口被CORS拦下来。因为前端页面是8080端口，Flask是5000端口，浏览器会认为这是跨域请求。解决办法有两个：一是在SSM的Controller层做一个代转接口，前端请求Java端带/recommend/**前缀的URL，Java端内部转发到Flask；二是在Flask里加CORS响应头。两种办法我在项目里都试过，推荐第一种，因为它还能顺便做权限控制，避免推荐接口被直接暴露出去。

5.5 功能验证流程

系统跑通后，按这个流程走一遍功能，能验证大部分核心模块：

1. 用管理员账号登录后台，新增一个景点，前台刷新后能看到新景点出现在列表里；
2. 用普通用户账号登录前台，进入广州城市分类的景点列表，把页面浏览一遍，然后去看收藏功能；
3. 在搜索框搜一个关键词，比如“海洋”，触发一次搜索行为；
4. 回到首页看“猜你喜欢”栏目，如果推荐列表里出现了海洋公园、海底世界这类景点，说明行为采集和推荐算法工作正常；
5. 在后台把刚新增的景点删除或下架，前台不再展示，说明联动正确。

这个流程全部走通，就说明你的Java端、Flask端、MySQL三条线已经是一个完整的闭环，演示给老师看的时候也胸有成竹。

6. 系统核心模块的“为什么”与进阶玩法

6.1 旅游线路规划是怎么实现的

旅游线路规划这个模块，听着挺玄，实际就是一个“关联查询+排序”的问题。线路表里存了“途经景点ID列表”，字段类型我建议直接用字符串存，比如“1,5,12,18”。展示的时候按逗号split成数组，再逐个查景点名称。这样设计牺牲了一点规范化，但换来了极大的实现便利，尤其适合毕设这种数据量不大但是急着跑通功能的场景。

线路推荐的功能逻辑是：根据用户当前选择的省份或城市，系统先把这个城市所有景点按热度值排序，再从前几位热门景点中随机组合出生成路线。这里的“随机”不是完全乱选，而是有约束的，比如同一条线路尽量不要有两个同类型的景点，海洋公园和海底世界放一起就重复了。

6.2 旅游美食推荐的数据怎么组织

很多同学容易把美食推荐做成一个和景点推荐完全割裂的模块，这是不对的。美食推荐应该和景点形成强关联。比如你正在看珠海长隆海洋王国的详情页面，美食推荐栏目应该优先展示横琴附近的生蚝或者海鲜餐厅，而不是推送广州的早茶店。

这个关联如果通过表结构来做，就是在美食表里加一个归属景点ID字段。每一家推荐的美食店铺都可以关联到一个景点上。推荐算法计算的时候，先找到当前用户正在看的景点，再把该景点关联的美食按热度值排列，输出前三名。这个流程写起来非常简单，但体验上会让人觉得“这个系统真的有脑子”。

6.3 热门推荐和个性化推荐如何共存

页面上同时存在“热门榜单”和“为你推荐”两个栏目时，两者的数据来源完全不同。热门榜单由热度值排序生成，是相对固定的；个性化推荐则要实时根据用户行为计算。

这里有一个体验细节值得注意：如果一个老用户的热门榜和个性化推荐出现了完全相同的内容，这不算bug，但影响观感。我实际调优时是把个性化推荐的topN稍微避开热门榜前5名。实现方案是在推荐结果过滤阶段，如果推荐项ID出现在热门榜前5，就往下顺延找一个替补候选。这样前端展示的两个栏目差异明显，用户会觉得系统真的有“智能推荐”在里面。

7. 部署与调试实录：常见问题速查与排查技巧

7.1 我给你整理的问题速查表

这是我带着这个项目走了一遍后，踩过或者见过别人踩过的典型问题，直接做成一个速查表，你遇到了可以直接对号入座：

7.2 三个要多留神的隐蔽问题

白屏问题。SSM项目里Controller返回路径配错很容易出现白屏，前台页面路径是/WEB-INF/views/下，配置视图解析器时如果前缀后缀写错，页面直接404或者500。排查时在浏览器按F12打开Network面板，看哪个请求返回500，然后对齐视图解析器配置。

跨域问题是老生常谈，但我发现很多人明明配了CORS还是报错，原因往往是Filter顺序问题。你的CORS过滤器必须在SpringMVC的DispatcherServlet之前执行，否则请求根本到不了CORS处理的那一步。如果是在web.xml里配置的，注意过滤器声明顺序越靠上越先执行。

也是我自己坑得最惨的一次，是本地运行一切正常，一到部署或者换机器就推荐结果有误。原因是硬编码路径。项目中任何地方凡是写了C:\Users\xxx\...这种绝对路径的，必须全部换成配置文件里的动态路径。包括上传图片目录、日志输出目录、Flask里读取资源的路径，一旦写死换机器就废。这也是Java项目里最常见的“能跑但不能部署”的根因。

7.3 推荐效果的调优方向

如果你想让推荐结果看起来更“聪明”一点，核心就盯一个指标：用户行为和推荐结果的吻合度。

你可以找一个用户，把他/她的浏览历史拉出来看一眼，再看他/她的推荐列表，如果推荐列表的景点标签和浏览历史景点标签重叠度很低，就说明行为权重或者标签计算有问题。调优时从两个方向入手：第一，提高搜索和收藏行为的权重，因为这两个行为比单纯的浏览更能代表用户真实意图；第二，给景点标签再做一次人工审核，把过于宽泛的标签改精确。举个例子，一个景点有“海洋”和“乐园”两个标签，比“好玩”“好看”这种屁用没有的标签强一万倍。

8. 论文与答辩：怎么把项目讲得比自己做的更厉害

8.1 LW论文的结构怎么搭

毕设论文一般都有固定的套路，但这个项目因为涉及双端架构，论文里建议按下面这个顺序来写，逻辑最顺：

• 第一章绪论，写清楚大湾区旅游信息化背景和推荐系统的价值；
• 第二章需求分析，把普通用户和管理员的功能需求列清楚，画用例图；
• 第三章系统设计，包括总体架构设计、技术选型、数据库设计、推荐算法选型；
• 第四章系统实现，按模块把核心代码截图和关键逻辑写出来；
• 第五章系统测试，写功能测试用例和结果；
• 第六章总结与展望，提一下推荐算法优化的方向和国内外发展的空白处。

论文写的时候有个高级技巧：把“为什么用SSM”和“为什么用Flask”单独作为一个小节来写，把“Java做业务管理、Python做推荐计算”这个技术决策讲透。这一段往往是你比同组同学看起来更专业的关键。因为大多数人的论文只会罗列“我用了什么技术”，很少能说清楚“我为什么这么分”。

8.2 答辩演示的节奏把控

答辩演示的时候别闷头点页面，要带节奏。建议的演示思路是：

先演示后台管理功能，速战速决，让老师看到数据是怎么维护的；然后演示前台核心功能，重点放在搜索和收藏后推荐列表发生了什么变化，让老师体会到“推荐系统”真的是在实时工作；最后打开代码重点讲两处：一是用户行为表的插入逻辑，二是Flask里推荐算法的核心函数，让老师觉得你既懂业务又懂代码。

答辩时老师最容易问的几个问题，我先帮你把参考答案想好：

• “你这个推荐算法和协同过滤有什么区别？”可以回答：项目以内容推荐为基础，通过标签匹配实现个性化，也参考了协同过滤中“物品相似度”的思路，属于两者结合。
• “数据量大了之后怎么办？”可以回答：引入Redis做推荐结果缓存，把推荐计算做成异步任务，再考虑用Spark或Flink做离线批处理。
• “Flask服务挂了会影响系统吗？”可以回答：主业务流程不受影响，但推荐功能会暂时降级为热门推荐，系统可以做熔断处理来保证可用性。

8.3 写在最后的一点经验

说实话，我刚接触这个项目时也踩了不少坑，尤其是Java端和Flask端联调那几天，一度被跨域和中文乱码搞得头皮发麻。但如果你耐下心去把“数据从哪来、怎么流动、最终返回什么”这条线捋清楚，这个系统其实非常通透。它不是一个炫技的项目，而是一个“把一个真实场景老老实实做落地”的完整范本。

最后再给你一个很实用的建议，如果你拿到源码准备部署，先从“一句话跑通”开始：配好数据库、导入SQL、启动Tomcat、启动Flask，先看到页面和数据，再动手改代码。不要一上来就埋头读代码，那样很容易陷进去出不来。系统跑起来之后，你对这个项目的理解深度会完全不一样。项目源码、LW、调试文档网上都能找到，但自己从头到尾跑通一遍、改一个模块、加一个小功能，收获比看十遍文档都大。祝你也把这条链路跑通。