Spring Boot热门网游推荐网站开发：从数据库设计到推荐机制

1. 项目定位与需求拆解

“热门网游推荐网站”这个题目，在高校的Web课程设计、毕业设计里面出现频率非常高。它看起来只是一个普通的资讯类站点，但如果你真把它当成“写几个页面、查几张表”的小作业来做，答辩的时候很容易被老师问住。反过来，如果你按产品思路去拆解，把推荐逻辑、用户体系、后台管理、文档完整性都做扎实，它完全可以作为简历上的一个亮点项目。

这个项目的核心价值在于：它不是一个纯粹展示型的静态网站，而是涵盖了前端页面、后端接口、数据库设计、会话管理、推荐排序规则、后台维护等多个模块的完整Web应用。从学习角度讲，它覆盖了Web开发的完整链路；从答辩角度讲，它每个模块都有可深挖的技术点；从实用性角度讲，它可以作为一个小型资讯类站点的通用模板，换一下数据内容，就能变成电影推荐、书籍推荐、工具推荐网站。

先说清楚需求层面。拆解“热门网游推荐”这六个字，至少能拆出四层含义：

• 第一层是“客户端展示”，用户能看到游戏列表、分类、详情、评分、推荐理由；
• 第二层是“推荐机制”，为什么热门？热门的依据是什么？是用户评分、浏览量还是管理员置顶？
• 第三层是“用户参与”，用户能不能收藏、评论、打分？这决定了网站是否具有互动性；
• 第四层是“后台管理”，管理员怎么录入游戏、上下线推荐位、处理用户数据？

很多同学做这个题目时只做了第一层，导致项目内容单薄，没有太多可以写的功能点。我的建议是，把四层全部做进去，至少做到第二层和第三层，第四层做基础版。原因很简单：课程设计和毕业设计的评分维度往往是“功能完整度 + 技术复杂度 + 文档规范度”，你多做一个用户收藏，就多一个数据表设计的说明，多一个前后端交互的接口展示，多一个答辩时能讲的业务逻辑。

下面从技术选型开始，完整走一遍这个项目的设计、开发、文档写作和部署流程。我以Java生态的Spring Boot方案为主线来讲，后面会补充说明PHP和Python方案的关键差异。整个项目的代码量不大，正常节奏下5到7天能完成开发和文档初稿，完全可以作为周期两周以内的课程设计。

2. 技术选型与开发环境准备

技术选型是整个项目中最值得花时间思考的环节。同一个题目，用JSP + Servlet做和用Spring Boot + Vue做，产出的项目体量、学习价值、答辩观感完全不同。我见过太多人用纯JSP + SQL拼一个网站交差，最后老师问“你这个项目用了什么设计模式”“会话管理怎么做的”“接口怎么设计的”，答不上来，分数自然不理想。

2.1 后端方案对比

当前课程设计、毕设项目中，主流后端方案无非三类：

作为参考，Spring Boot + Thymeleaf 是我个人最推荐的课程设计组合。它比JSP方案新了一个时代，又比前后端分离方案少了很多工程化负担。Thymeleaf是服务端模板引擎，写HTML时直接嵌入动态数据，后端返回一个视图名就能渲染整个页面，概念上更容易理解。再加上Spring Boot内置Tomcat，打包成jar就能跑，部署演示非常方便。

如果你所在学校对PHP有要求，或者你个人更熟悉PHP，也没有问题。PHP方案里我推荐选ThinkPHP框架，它自带一套标准的MVC结构和数据库操作封装，写起来比原生PHP快得多。核心流程和Spring Boot是殊途同归的，后端的控制器、模型、视图三层结构一套到底。我有个朋友曾经用ThinkPHP开发过校园兼职网站，同样的代码结构，MySQL表改了改，前后端页面重新设计，就变成了完全不同的作业。好消息是这款跨界能力对精通一种技术栈的人并不复杂。

2.2 数据库选型

数据库直接选MySQL，版本建议5.7或8.0。理由有三个：第一，市面上所有教程和博客都能直接用；第二，课程设计文档里写MySQL的优化、索引、事务都有大量现成素材；第三，你在学校机房或自己电脑上部署都毫无压力。如果你想让项目显得更有深度，可以在文档的“技术亮点”章节里提一句：使用了MySQL的InnoDB引擎，支持外键约束和事务，在评论和收藏功能中依赖事务保证数据一致性。这一句话，答辩时就能延伸出不少内容。

2.3 开发环境与工具清单

在项目正式开始前，我建议把环境整理好，避免开发中反复折腾。这是最容易被新手忽略的一步，上来就敲代码，结果环境配了三天，一半时间浪费在报错上。

• JDK：如果是Spring Boot 2.x，装JDK 8或11都行；如果选Spring Boot 3.x，需要JDK 17+。稳妥起见，课程设计用Spring Boot 2.7.x + JDK 8，资料最多、坑最少。
• IDE：IntelliJ IDEA Community版即可，免费且支持Spring Boot项目。如果你喜欢Eclipse，也可以，但IDEA的Spring Initializr集成更顺手。
• 数据库工具：Navicat或DBeaver，用于可视化管理MySQL。推荐DBeaver，免费、跨平台、对新手友好。
• 构建工具：Maven 3.6+，Spring Boot项目的标准构建方式，IDE一般自带，检查版本即可。
• 前端开发：不需要额外工具，纯HTML/CSS/JS，浏览器Chrome足够。如果你愿意用Vue，那是加分项，但不必须。
• 源码管理：Git，本地初始化仓库，提交记录完整。绝大多数同学不做这一步，但做了之后文档里能多一张Git提交记录截图，体现工程素养，很划得来。
• 接口调试：Postman或Apifox，用于测试后端接口。后面调试会话管理、数据接口的时候非常有用。

安装顺序建议是：JDK → Maven → MySQL → IDE → 数据库客户端 → 其他工具。安装完JDK后，命令行执行java -version确认版本；MySQL安装后记住root密码，最好设置一个和项目配置一致的密码，比如root/123456，开发期图省事，正式环境再换。

我自己在开发这类项目时习惯先把数据库建好，再用逆向工具生成实体类，最后写接口。这个顺序和很多人“先写代码后建表”的套路不同。原因后面在第4部分详细展开。

3. 数据库设计与推荐机制实现

数据库设计是推荐网站的核心业务环节之一。很多课程设计表设计比较随意，只有用户表和游戏表，功能上完全撑不起页面。我建议表结构至少覆盖以下六张：

• user（用户表）：存储系统用户，包括前台注册用户和后台管理员。字段有id、username、password、nickname、avatar、role、status、create_time。这里的password必须加密存储，用MD5加盐或BCrypt都行，如果你在文档里写“密码使用BCrypt加密存储”，这是一个标准的加分点。
• category（游戏分类表）：id、name、sort、status。分类数据少，比如角色扮演、策略、射击、竞速、卡牌、休闲这六个大类。之所以单独建表，而不是直接设计成游戏表的一个字段，是为了后面前台页面能按分类动态导航，后台能动态增删分类。
• game（游戏信息表）：id、category_id、name、cover_image、description、publisher、publish_date、platform、score、hot_value、is_recommend、status、view_count、create_time、update_time。这张表是业务核心，字段多，请认真设计。其中hot_value，即热度值，是“热门排行榜”的排序依据，也就是整个网站推荐的灵魂。is_recommend是首页推荐位的标记。
• comment（评论表）：id、game_id、user_id、content、score、status、create_time。评论功能是用户互动的重要组成部分，也是数据表关联（多表查询）的合理练习场景。
• favorite（收藏表）：id、game_id、user_id、create_time。收藏功能可以做成一个按钮，点击后往这张表插一条记录。它存在的意义不仅是让用户保存喜欢的内容，更在于让网站能够记录“用户偏好”，后续你可以据此扩展一个“猜你喜欢”模块。
• admin（管理员表）：如果不想跟普通用户混在一张表里，可以单独建。字段简单：id、username、password、last_login_time。有些项目用同一个user表加role字段区分管理员和用户，也可以，但单独建表在业务边界上更清晰。

六张表之间的关系很简单：game和category是多对一，comment和game是多对一，favorite和game是多对一，comment和user是多对一。外键关系在文档里要画清楚，这属于数据库设计章节的核心内容。

3.1 热度值计算逻辑

“热门网游推荐”的推荐机制我选择了一种透明、可解释的规则：热度值由用户的真实行为综合计算得出，而不是纯人工指定。计算公式为：

hot_value = view_count * 1 + favorite_count * 5 + comment_count * 10 + score * 100

这个公式的含义是：一次浏览加1分，一次收藏加5分，一条评论加10分，评分（0~5）按100倍加权。为什么要这么设计？因为评分代表用户对游戏的“质量认可”，是最不容易刷的指标，加权重高；收藏代表“下次还来”，偏好明确；评论代表“用户愿意花时间表达”，互动深度高；浏览量最容易注水，所以权重最低。公式在课件和文档中非常容易表达清楚，且答辩时能展示你对推荐业务的思考，比单纯按一个score字段排序更能说明能力。

实际开发中，view_count在游戏详情页被访问时自增；favorite_count和comment_count可以通过统计favorite表和comment表中对应游戏的行数获得。不需要维护冗余计数，写一个统计SQL或MyBatis的关联查询即可。排序时直接查询游戏表按hot_value倒序排列，取前N条就是热门榜单。

3.2 SQL表结构核心代码

下面给出游戏表和评论表的DDL，其他表同理，篇幅有限就不全部贴出来了。注意字符集统一为utf8mb4，防止中文乱码。

CREATE TABLE `game` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '游戏ID', `category_id` int NOT NULL COMMENT '分类ID', `name` varchar(100) NOT NULL COMMENT '游戏名称', `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图URL', `description` text COMMENT '游戏简介', `publisher` varchar(100) DEFAULT NULL COMMENT '发行商', `publish_date` date DEFAULT NULL COMMENT '发行日期', `platform` varchar(50) DEFAULT NULL COMMENT '平台：PC/主机/手游', `score` decimal(3,1) DEFAULT '0.0' COMMENT '用户评分', `hot_value` int DEFAULT '0' COMMENT '热度值', `is_recommend` tinyint DEFAULT '0' COMMENT '是否首页推荐', `status` tinyint DEFAULT '1' COMMENT '状态：1上架 0下架', `view_count` int DEFAULT '0' COMMENT '浏览次数', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category` (`category_id`), KEY `idx_hot` (`hot_value`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='游戏信息表';

CREATE TABLE `comment` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '评论ID', `game_id` int NOT NULL COMMENT '游戏ID', `user_id` int NOT NULL COMMENT '用户ID', `content` varchar(500) NOT NULL COMMENT '评论内容', `score` decimal(2,1) DEFAULT '5.0' COMMENT '评分', `status` tinyint DEFAULT '1' COMMENT '状态：1正常 0删除', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_game` (`game_id`), KEY `idx_user` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='评论表';

几个值得注意的设计细节：hot_value字段上建了索引idx_hot，因为热门榜单是高频查询，排序集中在hot_value列，加索引能提升查询效率。score用decimal而不是float，避免小数漂移。status字段统一存在，不物理删除数据，而是逻辑删除，这是好习惯，尤其是评论这种用户生成内容，物理删除不方便审计。

3.3 初始化数据准备

网站要有“推荐感”，必须有足够真实的预置数据。分类表先插入六条典型分类。游戏表建议至少插入15到20条游戏数据，名称可以用知名网游（比如仅作为示例提及通用类型描述，避免商标问题，可以直接用“某款MOBA类游戏”之类的代称）。每条数据要填完整的发行商、发行日期、平台、简介。封面图可以用本地占位图，也可以使用在线图片URL。

这里要专门提一个常见问题：如果你从网上下载了游戏截图，直接使用会有版权风险，课程设计阶段可能没人较真，但养成使用自己生成图片或用占位图工具的习惯更好。模拟示例如下：

游戏名：《星界远征》，分类：角色扮演，发行商：虚构工作室，发行日期：2023年5月，平台：PC，评分：4.5，热度值：860，简介：“一款以星际探索为背景的MMORPG，玩家可以自由探索星系，组队挑战副本，打造装备并参与大规模联盟战。”

这样插15条，首页看起来就像模像样了。还可以插一条管理员账号和两条普通测试账号，账号数据用SQL直接插入，密码预先加密。

4. 后端功能模块与接口开发

这一部分是项目的骨架工程。网上虽然可以找到很多课设代写服务的广告，但到了答辩和代码审查时，要能把每一行说清楚，自己做一遍是最有底气的。编码工作量实际上非常低，Spring Boot已经把大部分重复劳动省掉了。一个人从零开始，按顺序完成以下模块，每天4小时，5天足够了。

4.1 Spring Boot项目初始化

打开IDEA，选择Spring Initializr创建项目。Group填com.example之类，Artifact填game-recommend或者recommend-site。依赖选择：Spring Web、Thymeleaf、MyBatis或Spring Data JPA、MySQL Driver、Lombok。

ORM框架我推荐用MyBatis，为什么？国内技术栈用到MyBatis的场景非常广，面试和技术文档也比较常见。而且你写SQL时能更好地理解数据库操作。JPA虽然自动建表很方便，但把SQL全隐藏了，对课设项目来说有点“太魔术”，答辩反而难讲。用MyBatis，把SQL显式写在Mapper XML里，老师问起来就说：“这是手写的SQL，能精确控制查询逻辑。”加分。

当然，如果你Java基础弱，不想写XML，可以用MyBatis-Plus。MyBatis-Plus提供了极其丰富的CRUD方法，几乎不用写SQL。它会让你的项目代码量减少三分之一，而且依然是“有技术含量”的框架，写进简历也没问题。这里我不偏向任何一个，按你自己情况定。

4.2 实体类与Mapper层开发

根据数据库表，在entity包中创建对应实体类。Game实体类核心字段如下：

@Data public class Game { private Integer id; private Integer categoryId; private String name; private String coverImage; private String description; private String publisher; private Date publishDate; private String platform; private BigDecimal score; private Integer hotValue; private Integer isRecommend; private Integer status; private Integer viewCount; private Date createTime; private Date updateTime; private String categoryName; // 关联查询时使用，非数据库字段 }

这个categoryName字段是非数据库映射的扩展字段，用于存放多表查询时联查出分类名称。在MyBatis中，resultMap配置时需要有对应的映射处理。很多新手在这里踩坑——“为什么我的Game对象里categoryName总是null？”答案就是没有在resultMap中配置它的映射。

Mapper接口和XML对应开发，例如首页热门榜单的SQL如下：

<select id="selectHotGames" resultType="com.example.recommend.entity.Game"> SELECT g.*, c.name AS categoryName FROM game g LEFT JOIN category c ON g.category_id = c.id WHERE g.status = 1 ORDER BY g.hot_value DESC LIMIT #{limit} </select>

LEFT JOIN和INNER JOIN的区别，在这个场景下值得说明：LEFT JOIN保证即使某个游戏的分类被误删或未分配，游戏本身依然能查出来，只是categoryName为null。首页不应该因为关联不到分类就少一条游戏，所以用LEFT JOIN更合理。

4.3 Service层：业务规则与事务

Service层是业务规则最集中的地方，也是答辩时最能“讲故事”的层。包括查询游戏详情，需要在返回信息的同时，让浏览量自增1。这个操作虽然实现简单，但要注意它不应该影响主查询结果，也不该因为自增失败导致查询错误。更好的做法是把浏览量自增放在查询之后的更新语句里，用update语句单独执行。如果你要严谨一点，可以在Service层方法上加@Transactional，让“查询详情+自增浏览量”作为一个原子操作。虽然极端并发下两个用户同时操作有极小概率产生误差，但课设场景已经足够合理。

评论功能是另一个重点。用户发表评论后，游戏表的score字段需要重新计算该游戏所有评论的平均分，更新回到game表。这个过程必须要在Service层里按顺序完成，需要事务保证两步都成功。如果先插入评论，再更新评分，第二步失败怎么办？没有事务就会产生数据不一致。加上@Transactional后，任一步失败都会回滚。答辩时老师问到事务，这就是最完美的例子。

收藏功能的Service层也有类似逻辑：先检查是否已收藏，若已收藏则提示用户，不能重复收藏；保存到favorite表后，更新游戏的热度值或收藏计数。有一种更精细的做法：热度值不需要实时更新，可以定时用SQL聚合favorite表和comment表，统一计算所有游戏的热度值。比如每天凌晨跑一次。这种做法在文档里可以写“热度值为每日定时统计”，听起来更加工程化。

4.4 前端页面设计与后端渲染

热门网游推荐网站的页面数量，建议规划为六个视图：

1. 首页：热门榜单 + 推荐位 + 全部分类入口
2. 游戏列表页：按分类筛选、按热度/评分排序、分页展示
3. 游戏详情页：游戏信息 + 平均分展示 + 评论区 + 收藏按钮
4. 用户登录注册页：表单校验 + 验证码（可选）
5. 个人中心页：收藏列表、我的评论
6. 后台管理页：游戏列表管理、添加/编辑游戏、分类管理、评论审核

如果用Spring Boot + Thymeleaf，页面文件放在src/main/resources/templates目录下，按Controller返回的视图名匹配。页面间通过URL传参，比如/game/list?categoryId=1，Controller接收categoryId参数，查询分类下游戏列表，把数据放入Model，返回list.html。每次切换分类，浏览器自动发请求并刷新页面。

布局上建议做一个公共头部和底部，用Thymeleaf的th:fragment抽取公共部分，头部里放导航、搜索框、用户登录状态。Thymeleaf模板继承的语法，把header和footer抽成一个layout.html，其他页面引用。这个做法的好处是，所有页面的导航栏和用户状态一起变化，一个地方改，全站生效。

CSS样式是这门课最容易低分的地方。很多同学前端页面毛坯房一样，表格堆数据，按钮生硬，老师一看就觉得“不认真”。这块不用你写出惊艳的设计，用现成UI框架就足够好看。推荐使用Bootstrap 5或Layui，引入CDN即可，不需要下载本地文件。Bootstrap的栅格系统、卡片组件、导航栏，做这个网站绰绰有余。

4.5 登录注册与Session会话管理

“Session会话网站开发”相关热词的出现，说明登录会话管理是这个项目被反复讨论的环节。为什么？因为很多课设项目都能做到“能登录”，但很难说清楚“登录之后，网站怎么记住你的状态”。

原理很简单：用户在登录页面输入账号密码，后端校验通过后，把用户信息存进服务端的Session对象中。服务端会生成一个唯一的SessionId，通过Cookie写到浏览器。浏览器在后续每次请求中都自动携带这个Cookie（记住，请求头里的JSESSIONID或SESSION就是它），服务端根据SessionId找到对应的Session，从而识别出这个请求来自哪个用户。

需要注意，Session存在服务端内存中，浏览器关闭了Session不一定立刻失效，要靠设置超时时间。Spring Boot默认会话超时时间是30分钟，你可以在application.yml中调整：

server: servlet: session: timeout: 60m

但是问题来了：如果服务端Session存在内存里，项目重启后用户就全部掉线了。课程设计中无伤大雅，但如果你希望项目显得有深度，可以换成Spring Session方案，把会话数据存到Redis。这个需求需要额外引入spring-session-data-redis依赖，并在配置中指定存储类型为Redis。代码改动极小，但项目档案中能多写一个亮点：“实现了基于Redis的分布式会话管理方案。”这个知识点在毕业设计答辩时是很好的加分项。

登录验证的Controller实现如下：

@PostMapping("/user/login") public String login(String username, String password, HttpSession session, Model model) { User user = userService.login(username, password); if (user == null) { model.addAttribute("error", "用户名或密码错误"); return "login"; } session.setAttribute("loginUser", user); if ("admin".equals(user.getRole())) { return "redirect:/admin/index"; } return "redirect:/"; }

登录成功后通过session.setAttribute把用户对象放入会话。后续在任意Controller中需要获取当前登录用户，通过session.getAttribute("loginUser")即可。

注销时执行session.invalidate()，销毁整个会话，而不是只移除某个属性。这种细节，值得写进代码注释和文档里。

一个常见的需求：用户访问个人中心时，先检查是否已登录。这个检查逻辑每个需要登录的接口都要写一遍，非常冗余，且容易遗漏。正确做法是使用拦截器（HandlerInterceptor），实现一个LoginInterceptor，在preHandle方法中检查Session中是否存在loginUser，不存在则重定向到登录页。注册拦截器的Java代码大约二三十行，但防漏、清晰，且是“代码复用”的经典案例。

4.6 后台管理功能

后台管理是实现网站内容可维护的唯一途径。如果没有后台，添加一个新游戏就得手工改数据库，那这个网站只能算半个项目。有了后台，网站才真正“活”了。

后台需要实现的功能：

• 登录：管理员进入admin/index前校验用户角色是否为管理员
• 游戏管理：列表展示所有游戏，支持按名称模糊查询；点击编辑进入表单页，可修改所有字段；新增游戏；删除游戏（逻辑删除，把status设为0）
• 分类管理：新增、修改、删除分类。注意，删除分类时如果该分类下还挂有游戏，业务上应该提示“请先移除分类下的游戏”，而不是直接删除导致数据悬空
• 评论管理：列表查看所有评论，支持删除（逻辑删除）
• 数据概览：首页统计游戏总数、评论总数、用户总数、今日浏览量。这个功能很简单，几个count查询拼在一起。别小看这个页面，它让后台看起来像“管理系统”，而不是“管理表格”

前后台页面如何组织？最直接的方式是后台独立一个admin目录，所有后台页面的访问路径都以/admin开头，Controller里新建AdminController包下的一组控制器。后台页面用独立的布局，比如侧边栏+顶部导航+内容区，跟前台风格区分开。数据表格用Bootstrap的无样式表格，配上几个按钮，简单清爽。

4.7 Controller层与路由设计

路由设计要清晰，这是后端代码可读性的重要一环。推荐以下路由规划：

RESTful风格不一定要严格做到，但路径表达要让人觉得“有设计”。比如游戏详情用/game/detail/{id}而不是/game_detial?id=1，前者的路径参数传递是Spring MVC更推荐的做法，也利于文档中写接口说明。

5. 前端页面实现与交互设计

前端页面是评阅老师和答辩老师第一眼看到的东西。如果只知道后端一堆接口，前端页面粗糙，项目整体观感会大幅下降。网游推荐网站这类资讯型网站，重点是把信息展示得清晰，同时有一定视觉吸引力。

5.1 首页布局与推荐位设计

首页的布局建议按三块纵向排开。顶部是导航栏，包含站名、分类导航（动态从数据库读取）、搜索框、登录/用户信息入口。中间上半部分是热门推荐区，用轮播图或大卡片展示被标记为“is_recommend=1”的游戏，这个区域是视觉焦点。往下是热门榜单区，按热度值排序展示前10款游戏，左侧展示封面图，右侧展示游戏名称、分类、平台、评分，每条信息做成列表卡片。

分类导航的渲染用Thymeleaf循环页面：

<nav class="navbar-nav"> <li class="nav-item" th:each="cate : ${categoryList}"> <a class="nav-link" th:href="@{/game/list(categoryId=${cate.id})}" th:text="${cate.name}">分类名称</a> </li> </nav>

这个动态渲染的意义在于：后台管理员新增一个分类，前台导航自动多出一个入口，不需要改任何前端代码。这个“数据驱动页面”的点，在文档和答辩中都可以重点讲。

5.2 游戏详情页与交互逻辑

详情页是用户参与度最高的页面。布局建议：左侧封面大图，右侧游戏核心信息（名称、平台、发行时间、发行商、评分），下方是简介。右上角放“收藏”按钮和“评分”控件。如果用户未登录，收藏按钮点击后跳转登录页，这是常见的业务约束。

评论区放在简介下方，按时间倒序展示评论列表，每条评论包含用户昵称、评论时间、评论内容、评分星级。评论区底部是输入框，登录用户可以发表评论和评分。

这里有一个重要的用户体验细节：用户发表评论后，页面不能只是把数据提交到后端然后白白刷新留空白。一个比较好的做法是提交成功后重定向回详情页，Thymeleaf中代码为return "redirect:/game/detail/" + gameId。这样用户可以立即在评论区看到新评论，同时浏览器地址栏也保持正常。如果你用Ajax提交，就需要用JavaScript手动把新评论追加到评论列表，工作量稍大一点，但交互更好。

5.3 搜索与分类列表页

列表页要支持按分类筛选、按名称模糊搜索，以及按热度或评分排序。这三个条件组合起来，在Service层写一个动态SQL查询即可。MyBatis中可以用where标签拼条件，如：

<select id="searchGames" resultType="com.example.recommend.entity.Game"> SELECT g.*, c.name AS categoryName FROM game g LEFT JOIN category c ON g.category_id = c.id <where> <if test="categoryId != null"> AND g.category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND g.name LIKE CONCAT('%', #{keyword}, '%') </if> AND g.status = 1 </where> <choose> <when test="sort == 'score'"> ORDER BY g.score DESC </when> <otherwise> ORDER BY g.hot_value DESC </otherwise> </choose> </select>

动态SQL是MyBatis的核心能力之一，也是和“自己拼SQL字符串”的本质区别。这个片段值得你在文档里展开说明，解释每个if判断的作用。

6. 项目文档的写作策略与答辩准备

很多同学把这个项目做成纯粹“能跑就行”，等最后要交文档时才发现一个字也写不出来。文档和源码的重要性往往是对半开的，课程设计评分一般由“系统演示50% + 文档50%”组成，有些学校答辩表现还能再加分，所以文档质量直接影响最终评价。

6.1 文档结构框架

一份完整的课程设计或毕业设计文档，至少要有以下章节：

1. 绪论：项目背景、意义、国内外现状。网游推荐网站的背景可以从“游戏市场快速发展、用户信息过载、需要个性化推荐工具”切入。现状部分别写得太大，简单提两句目前主流游戏网站的核心功能即可。
2. 需求分析：功能性需求（游客浏览、用户注册登录、收藏、评论、后台管理等）和非功能性需求（性能、安全、易用性）。用表格罗列需求，比写段落更有节奏感。
3. 系统设计：包括总体架构（B/S架构图）、技术选型、数据库设计（ER图、表结构说明）、功能模块设计（用户端、管理员端）。这里的架构图用VISIO或draw.io画，数据库ER图用Navicat的逆向工程生成，也可以手绘。
4. 系统实现：按功能模块展开，每个模块放核心代码片段并辅以文字说明。代码不要贴一大段，挑关键的业务逻辑展示即可。
5. 系统测试：测试环境、测试用例表、测试结果分析。至少写8到10个测试用例，覆盖登录、注册、浏览、搜索、收藏、评论、后台管理、权限拦截等场景。
6. 总结：你在开发过程中解决了什么问题、掌握了哪些技能、还有哪些不足。这个章节要写得真实，比如“最初在设计推荐公式时忽略了收藏行为的权重，后来发现收藏量大的游戏不一定评分高，于是调整了权重参数”，这种反思比空话强一百倍。

6.2 文档写作需要避免的坑

文档最大的雷区是“论文变成代码说明书”。代码逐行翻译成中文，没有任何设计思路，老师一眼就能看出是应付。正确写法是“先讲为什么这样做，再配代码证明自己真做了”。

举个例子，写评论功能时不要只贴一个CommentMapper.java的接口代码，而是写：“评论功能需要保证评论与评分数据的完整性。实现时，在Service层添加事务注解，当插入评论或更新平均分任一步异常时，整体回滚。以下是关键代码片段……”这样代码只是论据，业务逻辑和设计思想才是正文。

第二个常见问题是测试部分写得假。很多同学把测试表格填得完美无缺，所有用例都是“测试通过”。这既不真实，也浪费了答辩展示机会。写一两个真实遇到并修复的bug，比如“评论后平均分显示为null，原因是score字段类型是decimal但初始为空，改为默认0.0后修复”，这种内容反而能让老师觉得你确实做了开发。

6.3 答辩准备要点

答辩的时候老师问的问题，大概就三类：功能类、技术类、设计类。功能类问题最简单，演示一遍即可。技术类问题是拉开差距的地方：Spring MVC的工作流程是什么？MyBatis的#{}和${}有什么区别？Session是怎么保持登录状态的？事务什么情况下会失效？这些高频问题建议提前背熟。

设计类问题则重点围绕推荐逻辑：为什么这样设计热度公式？数据量大之后这个公式还适用吗？如果要做个性化推荐，你有什么思路？参考答案是：当前热门榜单属于全局热度，后续可扩展基于用户收藏分类的协同过滤推荐，比如根据用户收藏的游戏分类，推荐同一分类下的高分游戏。这个回答已经是很务实的“展望”了，也展示了产品思维。

7. 项目部署与常见问题排查

7.1 本地运行与打包部署

开发完成后，要把项目打成可执行包，方便在教室或演示环境中展示。Spring Boot的项目打包命令非常简单：

mvn clean package -DskipTests

打包后在target目录下生成一个recommend-site-0.0.1-SNAPSHOT.jar文件。发布时执行：

java -jar recommend-site-0.0.1-SNAPSHOT.jar

默认端口是8080。如果8080被占用，可以在启动时指定端口：

java -jar recommend-site-0.0.1-SNAPSHOT.jar --server.port=8090

项目打包前注意检查application.yml里的数据库连接配置，确认指向的是你实际使用的MySQL连接地址。生产环境和本地环境如果数据库地址不同，最方便的做法是在启动命令中覆盖配置项：

java -jar recommend-site-0.0.1-SNAPSHOT.jar --spring.datasource.url=jdbc:mysql://192.168.1.100:3306/game_db

7.2 常见启动与运行问题

问题一：启动时提示数据库连接失败

检查三点：MySQL服务是否已启动；URL中的数据库名是否存在；用户名密码是否匹配。连接MySQL 8.0时，URL建议加上时区和编码参数：

jdbc:mysql://localhost:3306/game_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

不加serverTimezone会报时区错误。

问题二：页面中文乱码

原因大概率是数据库连接配置没有指定characterEncoding=utf8，或者建表时字符集不是utf8mb4。建议建库语句显式指定：

CREATE DATABASE game_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

把数据库、表、连接字符串三处全部统一，乱码问题的概率就基本为零。

问题三：Thymeleaf页面引用静态资源404

在HTML文件中，CSS、JS和图片路径必须使用Thymeleaf的URL表达式，比如：

<link th:href="@{/css/style.css}" rel="stylesheet">

直接写href="/css/style.css"在本地访问可能没问题，但通过Controller返回时，如果项目有context-path配置，就会找不到路径。统一用th:href和th:src，这个问题就不会出现。

问题四：Session失效导致操作后跳回登录页

如果用户在使用过程中频繁被要求重新登录，先检查application.yml中的session超时时间是否太短。另外，最常见的原因是项目重启导致Session数据丢失，开发过程中这算正常现象，不用特别处理。

7.3 功能层面的排查要点

评论提交后没反应，先看控制台有没有异常。绝大多数情况是SQL错误，比如user_id为null——用户未登录时提交了评论。解决方式是在前台提交按钮处判断登录状态，或者通过拦截器在非登录状态下禁止访问提交接口。

后台登录成功后跳转回首页，但没有进入后台。原因可能是登录逻辑中，角色判断和跳转路径写错了。建议登录Controller中增加role判断，管理员用户跳转/admin/index，普通用户跳转首页。同时后台的拦截器要检测session中用户的角色，不是管理员则拒绝访问。

8. 项目扩展方向与个人心得

这个项目如果只做到这里，它已经是一个完整、能演示、能答辩的系统了。但如果你的精力和时间允许，有几个扩展方向非常值得考虑，它们能显著提升项目的技术档次。

第一个方向是加上“个性化推荐”功能。当前热门榜单是全局热度，所有用户看到一样的内容。你可以做一个“为你推荐”板块，逻辑是用当前登录用户收藏的游戏分类作为条件，查询这些分类下评分最高、且用户未收藏过的游戏。一个简单的基于内容的推荐，用两三条SQL就能实现，但它让系统从“无状态资讯站”变成了“有用户画像的推荐系统”。这个关键词写进文档标题，项目辨识度直接上升。

第二个方向是引入Redis缓存。首页热门榜单被频繁访问，每次查询数据库会带来不必要的压力。引入Spring Data Redis，把热门榜单缓存到Redis，设置5分钟过期。在文档中解释缓存更新策略——后台修改游戏数据时清理缓存，5分钟过期兜底。这个设计在技术深度上直接拉开与普通课设的差距。

第三个方向是数据可视化。后台统计页面用ECharts展示各分类游戏数量、近七日评论趋势、用户收藏Top10。ECharts是纯前端图表库，画图很快，但功能效果很唬人。这属于低成本高收益的扩展。

最后分享几个我做这种项目积累下的经验。

第一，数据库设计阶段多花时间，后面能少走很多弯路。我在做第一个课设时没有设计分类表，把分类直接写在游戏表的字段里，结果后台想加个分类，要改表结构，代码也要动。踩过一次坑之后，凡是涉及“一类多”的数据关系，一律单独建表。

第二，推荐的逻辑一定要能讲出“为什么”。老师问“为什么这些游戏排在前面”，如果你回答“因为我把热度设置得高”，那和没有推荐机制没有区别。有清晰的公式、权重、设计考量，这本身就是项目的重要得分点。

第三，文档里不要放假测试。真正的测试记录哪怕有几个“失败”都没有关系，反而证明你测过。我见过太多文档测试表格里“100%通过”，一旦老师随机挑一个功能现场点几下发现报错，整个文档可信度就崩了。

这个项目做完之后，把它作为模板，换一下数据内容，改成电影推荐、书籍推荐、数码产品推荐，几乎不用改代码结构。它本质上是一个“内容推荐型网站”的通解。把这个项目做透，你已经不是在完成一个课设，而是在掌握一套可以复用的Web产品开发能力。