企业官网建设流程全解析

毕业设计做完那一刻，代码能跑，我以为自己已经稳了。结果一打开项目，登录页白屏，数据库连接超时，答辨现场我盯着黑黢黢的Beank背景手足无措。后来才明白，毕设和真实项目之间的差距，恰恰就藏在那些你平时没注意、文档里也不会细讲的细节里。这次我选的是"基于Spring Boot的游戏分享网站"，一个看上去并不夸张、但覆盖面足够完整的题目。今天就把我从需求拆解、表结构设计、功能实现到最终交付答辩的整套过程，连带踩过的坑，一次性讲清楚。

这套项目很适合正在准备Java方向毕设、但又不想把题选得太大导致失控的同学。也适合那些代码会写但不知道如何围绕"完整交付"组织工作的朋友。它不涉及高并发、微服务这些清载量重的话题，但Spring Boot、MyBatis、权限控制、文件上传、分页查询、数据统计这些基本功，一个都跑不掉。

1. 为什么选游戏分享网站这个题目：难度与答辩覆盖面的平衡

1.1 题目难度的真实区间

很多同学选毕设题目时容易走两个极端。一边是选太简单的，比如只有一个表的企业官网，代码两天写完，但到了答辩环节老师问"你的难点在哪里"，你根本答不上来。另一边是选太大的，比如"基于微服务的游戏社区平台"，光是服务拆分和部署就能把人拖垮，最后论文写得像功能清单，精力全耗在和环境作斗争上面。

游戏分享网站刚好落在中间那个舒服的区间：业务的实体关系不复杂，用户、游戏信息、分类、评论、收藏、点赞，一张ER图就能画清楚；但又不是单表操作那么机械，登录鉴权、文件上传、多条件检索、数据统计、后台管理，这些标准功能点全都能铺开，每一个细问下去又都能说上几句。

以我个人的实际体会来说，答辩老师见过最多的项目就是"管理系统"——学生管理系统、仓库管理系统、图书管理系统。不是说这类题目不能做，而是在选题创新性上天然吃亏。游戏分享网站把业务场景换成"游戏内容流通"，虽然底层的增删改查逻辑类似，但至少在探索场合多了一层业务包装，介绍项目时也更贴合年轻用户的日常经验，讲起来自然不少。

1.2 这个题目能覆盖哪些答辩考点

答辩时的提问方向，大致可以预测。基于Spring Boot框架本身，老师会问IoC容器、自动配置原理、starter机制这些；涉及数据访问层，会问MyBatis和MyBatis Plus的区别、实体映射、事务控制；涉及前后端交互，会问RESTful接口设计、JSON数据格式、跨域问题；涉及部署，会问Linux环境下的打包发布、数据库初始化。

游戏分享网站恰好能把这一串考点全部串起来。用户登录用Spring Boot的拦截器或Shiro做会话管理，游戏信息发布涉及文件上传与静态资源映射，列表页涉及分页查询和多条件拼接，后台首页涉及简单的数据统计图表，这些都是可以放大讲细节的切入面。

所以，这个题目的核心价值不是"创新"，而是"完整"。它能让你在一套相对标准的架构里，把Java Web开发的主线全部走一遍。对你个人的提升，对评委老师的满意度，都有保障。

2. 做分析时最该花时间的地方：需求边界表结构流程图

2.1 先明确角色的边界

我见过不少做项目的同学，一上来就打开IDE开始建Entity类，结果写到一半突然发现"管理员审核游戏"这个功能没有对应的页面入口，然后又回头补页面、补接口。这种开发顺序的混乱，根源在于需求没有拆清楚。

游戏分享网站最少需要两类角色：前台普通用户和管理员。普通用户能做什么？注册登录、浏览游戏信息、按分类或关键词检索、查看游戏详情、对游戏进行评论、收藏游戏、在自己的个人中心管理已收藏内容和已发布分享。管理员能做什么？登录后台、维护游戏分类、管理用户状态、审核游戏信息、处理举报评论、查看基础统计。

着两张图，角色的边界就完全清楚了。再往下拆，普通用户的操作集中在浏览和交互层面，管理员的操作集中在内容治理层面。

2.2 核心数据模型的设计

建表是整个项目的地基。表结构设计不合理，后面写代码时处处受牵制。我这里把几个核心表的结构分享出来，同学可以直接参考改造。

用户表是这个项目的核心主实体。它至少需要包含用户ID、用户名、密码、昵称、头像地址、个性签名、角色标识、状态、注册时间这几个核心字段。特别注意角色标识的设定，可以用一个int字段，0代表普通用户，1代表管理员，不推荐用字符串，后续判断逻辑时int更省事。密码字段必须存储加密后的密文，这个问题后文单独讲。

游戏信息表是整个系统的内容基底。字段包括游戏ID、游戏名称、游戏封面图URL、所属分类ID、游戏简介、开发者或发行商、发布时间、配置要求概述、下载地址链接、浏览量、点赞数、发布状态、审核状态、发布者ID、创建时间。这里有一个关键点，游戏信息的"发布状态"和"审核状态"是两套不同的逻辑，前者是用户在前台操作层面的可见性，后者是管理员内容审核层面的合法性，写代码时不要混淆成一单字段。

评论表的核心逻辑是"用户与游戏之间的关联"。字段包括评论ID、游戏ID、用户ID、评论内容、回复的目标评论ID（为空表示顶级评论）、评论时间、删除标记。用"目标评论ID"做回复链设计，比单纯外键区分主评论和回复更方便前端展示。

收藏表相对简单，两个外键指向用户ID和游戏ID，加上创建即可。点赞表类似。这两张表没有冗余字段，属于记录型表，查询时通过联合唯一索引避免重复操作。

分类表就是一个典型的主子分类结构。表结构非常简单，分类ID、分类名称、父级ID、排序值。虽然游戏分享网站的垂直内容不太深，但做两层分类足够应对扩展情况。

2.3 核心流程要画给自己看

数据模型出来后，下一步是梳理核心流程，这一步价值比想象中要大。我自己通常会画三种图：用户使用流程图、管理员审核流程图、数据变更流程图。

用户使用流程不复杂：注册登录→浏览游戏列表→点击详情→发表评论→收藏游戏→在个人中心看待收藏和发布的分享。管理员审核流程则是：登录后台→看到待审核列表→查看详情→通过或驳回。数据变更流程需要想清楚的是：一条游戏信息从被用户创建、提交审核、审核通过、前台可见、被收藏被评论，整个生命周期里，每个节点的状态取值是什么，由谁触发变更。

这些图画完以后，开发的时候效率会高很多，因为你已经不需要边写边想了，直接照着图把代码填进去就行。说白了，毕业论文要的"可行性分析""需求分析"这些章节，全是从这些图里出来的，你现在画好，写论文时也可以直接用。

3. 技术栈选型：Spring Boot加MyBatis Plus的经典组合

3.1 组合选择的逻辑

Spring Boot在当前Java生态里已经是事实上的标准，自动配置配合起步依赖，能省掉大量早期Java Web开发时的配置繁琐问题。我的建议是Spring Boot直接选2.x稳定版本，配合JDK 8或11，这两个都与大多数实验室和在线部署的环境兼容性较好，不至于在环境上耽误太多时间。

持久层我选的是MyBatis Plus。为什么不是Hibernate或JPA？Hibernate在实体关系映射上功能很强，但查询灵活度不如MyBatis；原生MyBatis又需要自己写大量XML和分页语句。MyBatis Plus刚好在两者之间取了个平衡：单表增删改查可以直接用内置方法，遇到多表关联和复杂统计时也能用注解或XML自定义SQL，这种灵活性非常契合毕设项目的开发节奏。

前端方案上，我选择了传统的服务端模板渲染加一点JavaScript交互的组合。你可以用Thymeleaf作为模板引擎，配合Bootstrap整体布局，加少量jQuery和原生JS处理Ajax请求。这种选择的原因很现实：相比Vue加Spring Boot的前后端分离架构，服务端渲染的调试链路更短，不用考虑跨域问题、Token刷新这些额外复杂度。

3.2 开发环境与版本搭配清单

我把自己开发时确认无误的一套环境组合贴出来，可以直接照配：

这里有一个容易被忽略的小坑：MySQL 8.0的JDBC驱动名是com.mysql.cj.jdbc.Driver，连接串还必须带serverTimezone=Asia/Shanghai参数，否则本地跑时会有时区警告甚至报错。肖似MySQL 5.7时驱动名是com.mysql.jdbc.Driver，版本不同不能互相抄配置。

3.3 项目目录结构的组织经验

包结构的规划对论文的"系统设计"章节很有用，建议按功能模块分包，而不是按技术分层分包。我的做法是：

com.example.gameshare ├── controller ├── service │ └── impl ├── mapper ├── entity ├── dto ├── vo ├── common │ ├── config │ ├── interceptor │ ├── utils │ └── result

controller层只负责参数接收和结果返回，业务逻辑全部下沉到service层。这种分层看似多写了一些代码，但优点是后期定位问题非常快，而且论文里的架构图描述起来也更清晰。真实项目里这种分层习惯同样重要，这不是炫技，是基本的工程素养。

4. 核心功能从零到一的实现过程

4.1 登录鉴权：从拦截器到会话管理

登录鉴权是整个项目里最早也需要先确定的技术点。如果你用JWT做前后端分离的Token方案，代码复杂度会明显上升；而在服务端渲染的模式下，更合适的方案是使用Session加拦截器。

具体实现思路是：用户经用户名密码登录成功后，将用户ID和用户名存进Session；自定义一个LoginInterceptor，在preHandle方法里判断Session是否为空；通过WebMvcConfigurer注册拦截器，并指定放行路径——登录页、注册页、首页、游戏详情页、静态资源路径全部放行，其余路径全部拦截。

密码的加密处理上，务必使用BCrypt加密。Spring Security框架单独引入全套可能过重，但我们可以单独引入spring-security-crypto这个轻量依赖，只使用其中的BCryptPasswordEncoder类，既满足安全性又没有引入整个权限框架的学习成本。真实项目里密码明文存储是绝对红线，哪怕只是毕设也要养成这个习惯。

注册功能的逻辑要额外注意一点：用户名唯一性校验必须做在学校层面，也就是先查数据库再插入。同时前端也要做一次非空和格式校验，双重校验能避免绝大多数因误操作造成的异常。

4.2 游戏信息的发布与多条件分页检索

游戏信息发布涉及文件上传和表单提交两个动作。我在设计表单时，将基本信息字段与图片文件分成两个接口来处理，日志为先上传封面图到服务器指定目录，得到图片访问路径，再将这个路径作为一个普通字符串字段随表单提交。这样实现的好处是降低单一接口的耦合性，前端监控上传进度也更方便。

文件上传实现需要注意两点：一是处理上传目录的绝对路径映射，不能拼错；二是一切POST请求接口的编码格式必须设为multipart/form-data。我一般自定义一个WebMvcConfigurer，将本地磁盘的上传目录映射成/upload/**这个虚拟路径，这样页面内就能直接使用相对路径访问图片。

列表检索页面是体现基本功的地方。多条件组合查询包括：游戏名称模糊匹配、分类过滤、状态过滤，以及按发布时间或热度排序。使用MyBatis Plus的话，可以通过LambdaQueryWrapper拼装条件，再交给分页插件处理。分页插件记得配置拦截器，否则你会发现page方法分页失效，查出来永远是全量数据。

4.3 评论回复与收藏点赞：环环相扣的交互逻辑

评论交互算是这个项目里稍显复杂也容易写砸的部分。我的评论表设计中用parent_id字段区分顶级评论和回复，前端展示时先查顶级评论列表，再为每个顶级评论查询其回复列表。这样实现简单，但注意不要用递归查库的方式写，性能会很差。正确做法是一次性查出当前页所有目标的评论，再在内存里组装成树形结构。

没有做彻底删，逻辑思路是管理员后台的删除操作只是标记删除，前台查询时统一加deleted = 0条件。这样设计的好处是用户的历史评论内容仍可追溯，也模拟了真实业务中"软删除"的操作思路。

收藏与点赞的处理较为直接：用户点击收藏按钮，前端发送Ajax请求，后端判断是否已存在记录。存在则取消，不存在则新增，同时同步更新游戏表里的收藏数字段。唯一需要注意的是数据库层别忘了加联合唯一约束，否则用户拼命点击时，有可能生成重复记录。

4.4 用户个人中心与后台统计

个人中心相当于用户所有行为数据的汇总页。它需要展示：用户发布过的游戏信息列表、用户收藏的游戏列表、用户的评论记录。这三块都是典型的关联查询，但都不复杂，核心就是WHERE user_id = ?过滤加上多表JOIN获取关联名称字段。

后台统计页面适合用简单的ECharts折线图或柱状图展示近7日的注册用户数和游戏发布数。数据来源是两个统计SQL：按日期分组统计用户创建数量，按日期分组统计游戏信息创建数量，返回List<Map<String,Object>>格式，前端JSON解析后直接传图表配置项。图表功能在系统中的定位是"亮点"，有了它无论是从论文截图还是演示效果上都会更拿得出手。

5. 开发中我踩过的坑和对应的排查思路

5.1 分页查询结果一直是全量数据

这个坑我印象特别深。原本以为按文档配置了MybatisPlusInterceptor添加PaginationInnerInterceptor就没问题了，但实际一跑，page方法总是返回全部记录。检查了很久才发现，Maven依赖里虽然引入了分页插件，但配置类没有被Spring扫描到——类的包路径写错了，没有放在Spring Boot启动类同包或子包下。组件扫描默认只扫描启动类所在包及其子包，这是Spring框架的基础规则，但越是基础越容易忽略。

排查不出来的问题时，先看看控制台打印的SQL语句，再确认配置类是否真的生效，比反复改代码高效得多。

5.2 文件上传成功但页面图片不显示

这个坑的典型特征是：磁盘目录里有文件，数据库路径也存了，但前端访问图片时报404。根因是资源映射没配置。Spring Boot默认只映射classpath:/static/目录，你上传到的自定义磁盘路径是不会暴露给浏览器的。处理方式也很简单，新增一个配置类，重写addResourceHandlers方法，把本地磁盘的物理路径映射成一个可访问的URL前缀。还有一点要注意，当项目打成JAR包部署后，上传目录不能放在包内部的classpath中，必须放在服务器外部目录，否则每次重新部署文件就清零了。

5.3 接口调试时总是莫名其妙的404

这类问题多出现在路径映射上。有的是Controller类上用了@RequestMapping("/game")，方法上又写@PostMapping("list")，漏了斜杠访问变成/gamelist；有的是参数通过@RequestParam接收，但前端传的是JSON体，导致参数绑定失败。排查技巧是打开Spring Boot的日志级别，把logging.level.org.springframework.web调成DEBUG，启动时控制台会把你收到的请求URL、HandlerMethod全部打出来，一一对照就能快速定位。

5.4 用Lombok生成实体类后接口返回出现循环引用

当你的实体类互相包含时，比如用户表里有游戏信息列表，游戏信息表里又包含用户字段，JSON序列化时会发生无限递归，前端显示乱码或者请求直接报错。这个情况可以用@JsonIgnoreProperties注解在倒置关系中忽略某一方向的序列化，或者干脆在查询结果时使用VO类，只返回需要的字段。毕设阶段采用VO类是更干净的方式，既避免循环引用，也让前台返回的数据结构更可控。

5.5 MySQL连接时报Public Key Retrieval

使用MySQL 8.0时，如果连接串没有配置allowPublicKeyRetrieval=true，会出现一个连接被拒绝的异常。这是一个安全参数，开发环境下设为true即可解决。虽然不推荐生产环境这么开，但毕设部署在自己的服务器或实验室就是开发环境，问题不大。真正上线前，把密码加密、连接池参数、SSL配置这些重新打磨一遍就可以。

6. 从"代码能跑"到"顺利答辩"：构建完整的交付闭环

6.1 演示数据的重要性远超你的想象

这个建议我放在最后说，也是我吃亏最多的地方。很多同学做毕设时默认打开首页看到的是空数据，然后系统演示环节往往就变成了"我点这儿会跳到那儿、这个地方填了数据会有反应"的口头描述。评委老师是看不到你预期效果的。

正确做法是准备一套丰富、美观、贴近真实场景的演示数据。游戏分类至少建6到8个，游戏信息填充20条以上，每一条的封面图、简介、配置要求内容都要完整；注册两个模拟用户（一个是普通用户，一个是管理员），并造出用来展示点赞、收藏、评论交互的数据。这样一来，开场演示时即便一句话不说，光是滚动页面评委就能感受到这个系统的完整度。

6.2 拿捏答辩节奏：功能演示顺序的设计

答辩时功能演示的顺序也很关键，不要从管理员登录后台开始。我所知的最佳顺序是：先展示前台首页的布局和功能，演示游客视角如何浏览游戏和数据搜索；然后登录普通用户账号，展示收藏、评论、个人中心；最后切换到管理员账号，展示内容审核与用户管理的完整闭环。这样下来，从业务的用户视角到管理者视角就都覆盖了，评委老师完成能跟着你的节奏走。

6.3 论文、部署说明、演示视频的准备顺序

开发完毕之后不要急着写论文，先动手把部署说明文档写好。这里有一个非常实用的技巧：部署文档在项目开发中边改边记录，每一步做了什么、用什么命令启动、数据库初始化脚本涉及哪些表，随时充实，保证最后写出来的是一份照做就能跑通的文档。

演示视频的录制顺序建议是"从部署到功能"。先展示项目如何启动（IDEA运行方式或JAR包方式），再展示前端、后台、交互的完整流程，视频不用太长，控制在10分钟以内。这里的小经验是录屏前把浏览器缩放比例调到80%，让整体界面看起来更完整，分辨率1080p为宜，压缩过度的视频在教室大屏上展示效果会差很多。

论文写作方面，核心是把握"需求分析—系统设计—数据库设计—功能实现—系统测试"这条主线。数据库设计章节把表结构和ER图贴好，功能实现章节按模块逐个写清楚表关联与关键代码逻辑。论文不需要过度堆技术，重点是展现出你对系统整体结构的理解和代码动手能力。

最后再说一点技术之外的东西：毕设一路走下来，我最大的感受是"完整交付"这四个字的分量。拿游戏分享网站这个题目来说，从最初的想法到表结构成型，从一行行接口到页面一点点渲染，从部署文档一版版迭代到答辩PPT最后一页，整个过程的节奏感很重要。你写下的每一行代码，都不是为了凑代码量，而是为了回答评审时的某一个潜在问题。当你顺着这个思路去推进项目时，质量和深度自然不会差，而这也恰恰是整个毕业设计最有价值的地方。