企业官网建设流程全解析

每年到了毕业设计季，后台私信里堆得最多的一个问题就是：Java方向的毕设到底选什么题目最稳。我的回答里一直有一个固定选项——基于Spring Boot的个人博客网站。这个题目不惊艳，但胜在结构典型、技术栈通用、业务链路完整，从博客信息管理到分类管理再到评论管理，几乎覆盖了一个Java Web系统该有的全部核心环节。这篇文章我就把这个题目的完整做法从头到尾拆一遍，包括需求分析、数据库设计、后端实现、部署交付，以及论文和演示视频这些被很多人忽略的"临门一脚"，给正在做或者准备选这个题目的同学一条可以直接参考的路。

1. 选题拆解：个人博客网站这个经典题目到底在考什么

1.1 为什么Spring Boot成为毕设默认答案

先说一个很多同学没想明白的问题：为什么现在几乎所有Java毕设都默认基于Spring Boot？答案其实很现实——Spring Boot让大家把精力从"配置环境"转移到"写业务代码"上。早些年做SSH（Struts+Spring+Hibernate）或者SSM（Spring+SpringMVC+MyBatis）框架整合，光配置文件就要折腾好久，各种XML、各种jar包冲突，很多同学还没开始写功能就已经被环境劝退了。

Spring Boot的意义在于它把那些繁琐的框架配置变成了"约定大于配置"。你只需要引入相应的starter依赖，启动类一写，项目就能跑起来。而且它内置了Tomcat，打成一个jar包就能直接运行，这对后面部署环节来说简直是降维打击——你不需要教评审老师怎么在Tomcat里部署war包，只需要告诉他java -jar xxx.jar就够了。

回到选题上，个人博客网站为什么是"安全牌"？因为它踩中了毕设评审的几个核心考察点：一是CRUD（增删改查）基本功，二是表与表之间的关联关系设计，三是简单的权限控制逻辑，四是前台展示与后台管理的界面划分。这些点做扎实了，答辩基本问不倒。

1.2 标题里三个关键词背后的真实考点

"博客信息管理博客分类管理博客信息评论"这个连续串词看起来像复读机，但实际上它点出了系统的三大核心模块，也是考察的重点区域。

博客信息管理，核心考点是文章的增删改查、分页查询、搜索过滤、富文本编辑。这个模块决定了你的系统是不是一个"能用的系统"而不是"花架子"。分类管理，看起来最简单，就一个名字加描述，但它的考点在分类和文章的一对多关系如何处理，以及分类为空时删除策略如何设计。评论管理，是整个系统技术含量相对高的模块，因为它涉及多表关联查询（评论关联文章、关联用户）、可能有父子回复层级关系、还可能涉及评论审核状态的切换，这一块做好了，答辩时很有说头。

理解了这个考察逻辑，你后面做功能的时候就会知道哪些地方必须做深一点，哪些地方可以简单带过。比如文章标签如果不会做，就不如不做，做一个半吊子的标签系统反而会被追问到说不出话。

1.3 交付物清单：不止是代码那么简单

一个完整的毕设交付物，不只是把源码交上去就算完事。以这个题目为例，我建议至少准备六样东西：可运行的源码、论文（LW）、部署说明、演示视频、数据库脚本、答辩PPT。很多人把前两样看得太重，把后几样当成应付了事，这是完全错误的。

部署说明的价值在于让评审老师或者下一位接手的人能快速把系统跑起来。如果你写的部署说明让老师照着做了三个小时都没跑起来，那你的代码质量再高也会被打折扣。演示视频更是很多人彻底无视的东西，但我可以负责任地说，一个有脚本、有重点、录制清晰的演示视频，能在你们没法到场演示的情况下帮你保住大部分印象分。后面我会专门写一个录制演示视频的实操套路，这里先按下不表。

2. 地基先行：技术栈选定与数据库表设计

2.1 兜底最稳妥的一套技术组合

做这个题目，我不建议追求技术新鲜感。什么Spring Cloud、分布式、消息队列，这些名词放在个人博客上本身就是违和的，评审老师一听就知道你在堆砌概念。比较稳妥的组合是这样的：

后端用Spring Boot 2.7.x版本，这个版本还算新，且兼容性好，网上资料也多。持久层用MyBatis-Plus，它比原生MyBatis省掉大量重复的SQL编写，同时保留了SQL可控性。数据库用MySQL 5.7或者8.0都可以，推荐8.0，因为字符集和性能更好些。前端部分有两种选择：一是传统方式用Thymeleaf模板引擎直接写页面，二是前后端分离用Vue来写。对于毕设这个体量，我更推荐Thymeleaf方案，理由很实际——减掉一个前端工程，代码结构简单很多，答辩时你解释起来也更容易。

如果你非要前后端分离，那也可以，但你要有能力解释清楚跨域问题是怎么处理的，以及为什么你的接口设计成这个样子，多一个环节就多一个被追问的入口。

2.2 四张核心表的字段设计

个人博客系统在设计层面其实非常单纯，核心就四张表：用户表、文章表、分类表、评论表。但就这四张表，字段设计好了就是四两拨千斤，设计不好后面写代码处处别扭。

用户表的核心字段要有主键ID、用户名、密码（注意必须是经过哈希加密的，不能明文存储）、昵称、头像URL、角色类型（管理员和普通用户，这个字段是为了后面权限控制用的）、创建时间。文章表是四张表里信息量最大的，需要包含：主键ID、标题、摘要（列表页展示用）、正文内容（往往是富文本内容）、封面图URL、所属分类ID、作者ID、浏览量、状态（草稿/已发布/已下架）、创建时间和更新时间。分类表要有一个排序字段，别小看这个sort_order，分类列表的展示顺序如果没有排序字段，就只能按创建时间排，实际使用时会很难受。评论表要有主键ID、文章ID、用户ID、父评论ID（这个字段是为了实现楼中楼回复，没有它就只能做一层评论）、评论内容、点赞数、状态（正常/待审核/屏蔽）以及创建时间。

需要提醒的是，如果使用MyBatis-Plus，建议统一开启逻辑删除字段（deleted）和自动填充字段（create_time、update_time）。逻辑删除的好处是删除文章时数据不会真正消失，自动刷新页面还能从回收站恢复，这种小细节写进论文里也是亮点。

2.3 表之间怎么关联，查询为什么必须用JOIN

这几张表的关系其实一句话就能概括：分类与文章是一对多，文章与评论是一对多，用户与文章、用户与评论都是一对多。在数据库层面，文章的category_id指向分类表的id，评论的article_id指向文章表的id，评论的user_id指向用户表的id。

这里有个很多新手会犯的错误：在文章表里冗余存一个分类名称字段，而不是存分类ID。这样做会导致一个问题——当后台修改分类名称时，所有引用这个分类的文章也得一起更新，否则就出现数据不一致。正确的做法是用外键逻辑关联（不一定要真的在数据库里建物理外键，但Java实体类里要有关联字段），查询时用JOIN或者MyBatis-Plus的关联查询把名称带出来。

实际的SQL场景很简单：文章列表页需要展示文章TITLE、浏览量、所属分类名、作者昵称，这一条查询就要JOIN分类表和用户表。评论列表页需要展示评论内容、评论人昵称、评论所属文章标题，这就要JOIN用户表和文章表。能把这两条SQL写明白，表关系设计这关就算过了。

3. 核心功能实现：文章、分类、评论三条主线的编码思路

3.1 博客信息管理的增删改查、富文本与分页

博客信息管理是系统的绝对核心，它的代码质量基本决定了你整个项目的评分档位。先说分页查询。用MyBatis-Plus的话，分页依赖一个分页插件，在配置类里注入PaginationInnerInterceptor，然后查询时通过Page<T>对象配合selectPage方法就能搞定，不需要手写limit语句。这一步看起来简单，但记住一个坑：分页插件一定要配置数据库类型，否则方言判断错误会导致SQL异常。

然后是增删改查的细节。新增文章时要处理一个很容易忽略的问题——文章摘要。很多同学设计文章表时有摘要字段，但是新增接口里根本没有传摘要，前端也没填，结果列表页就显示一片空白。最简单的做法是后端根据正文内容自动截取前N个字符作为摘要，如果前端传了摘要就用前端传的，这样无论如何都不会空。删除文章建议用逻辑删除，前面已经说过，这里不再重复。修改文章时要注意同时更新update_time，这个字段如果不变，别人会怀疑你的更新逻辑是不是有Bug。

再就是富文本编辑器。这一块我强烈建议不要把体验做得太复杂。用业界成熟的wangEditor或者UEditor，前后端只管接收HTML字符串、存储、回显就行。唯一的坑是图片上传：富文本里插入图片时会向后端发一个上传请求，你需要单独准备一个上传接口保存图片，然后返回图片URL来让编辑器回显。如果这个接口没做，前端就会显示一堆"无法加载的图片图标"。别忘了在Spring Boot里配置静态资源映射，让上传的图片能被访问到，否则图片存进去了但URL访问不了，等于白做。

3.2 博客分类管理：树形结构还是扁平结构

分类管理模块有两种设计思路，一种是把所有分类做成扁平的列表，另一种是做两级树形结构（父分类+子分类）。个人博客这种场景，我建议做扁平的，原因有两个。

第一，从产品体验上看，个人博客的分类通常就几个或十几个，做树形结构多一层展开和收起，反而让访客觉得繁琐。第二，从代码实现来看，树形结构需要递归查询、层级路径维护，一个简单题目没必要引入这种复杂度。但是注意，如果你论文里想多写一点东西，那么两级分类也不是不行，只是答辩时你要能解释清楚"你的分类层级是固定的两级还是有多个子级"以及"叶子分类被删除时父分类下的文章如何处理"，这两个问题想不清楚就会被问倒。

分类管理的核心是它的删除策略。一个分类下可能有文章，那直接删分类就会把文章置于无分类状态。这有几种处理方案：方案一是删除分类前检查该分类下是否有文章，有文章就拒绝删除并提示用户先转移或删除文章；方案二是删除分类时把该分类下的文章全部移到"未分类"这个默认分类中；方案三是一次性把文章也删除。方案一最稳妥，逻辑简单，用户体验也能接受，推荐采用。把这些判断写在Service层而不是Controller层，不要让Controller里塞要么长的一段业务逻辑，这也是答辩时一个加分的编码习惯。

3.3 评论的无限级回复设计与审核开关

评论模块是整个系统的技术亮点，值得认真对待。如果只做一层评论（所有评论平铺），功能上说得通，但答辩时缺少一个展示数据结构设计的点。我建议做两级评论：顶级评论和回复评论。实现方法是在评论表里加一个parent_id字段，顶级评论的parent_id为0，回复某一个顶级评论时，parent_id存顶级评论的ID。如果要支持楼中楼（回复某条回复），则需要加一个reply_user_id字段来记录被回复人的ID，这样才能做到"某用户回复了某用户"的效果。

在查询评论列表时，比较高效的做法是分两步走：先查所有顶级评论，再一次性查出这些顶级评论下的所有子评论，然后在内存里做组装。不要循环查库，比如有100条顶级评论就查100次数据库，这在答辩演示时一旦评论多了就会卡顿，观感非常差。组装逻辑可以用一个Map以顶级评论ID为Key，把对应的子评论List放进去，一次遍历就能完成层级结构。

另外还要做一个评论状态的开关。为什么需要审核状态？因为如果你做的是开放式系统，任何访客都能提交评论，就会出现垃圾评论甚至带链接的广告。后台要能随时把某条评论设置成屏蔽状态。加上这个状态字段之后，你的后台管理页面就多了一个评论管理Tab：列表展示所有评论，标明所属文章和评论人，管理员可以一键屏蔽。这些交互看起来很普通，但构成了一个完整的"审核-展示-管理"闭环，答辩时能讲篇幅就长了。

4. 登录鉴权与接口层细节：答辩时最容易追问的地方

4.1 登录方案选择：用Token还是Session

个人博客系统虽然是一个偏展示型的项目，但后台管理毕竟需要登录才能操作，所以登录鉴权是绕不开的一环。现在主流的方案有两种：Session方式和Token方式（通常是JWT）。

Session方式配合Spring Security使用，是很多课程设计里常见的做法，优势是"过时但成熟"，但一个问题：前端页面如果是Thymeleaf服务端渲染的，用Session确实顺理成章；如果是前后端分离的，Session的跨域处理比较麻烦，你还要配置CORS。Token方式是目前企业里比较主流的做法，登录接口校验用户名密码成功后返回一个JWT字符串，前端存在localStorage里，后续请求在请求头里带上Authorization: Bearer xxx，后端再写一个拦截器统一解析Token并把用户信息放入当前上下文。

如果让我推荐，我会建议JWT方案。理由有三个：一是它的逻辑在答辩环节更容易讲清楚，你不需要铺垫一堆Session共享、Cookie作用域的冷知识；二是符合目前行业的普遍认知，老师听起来会觉得你了解当前的技术趋势；三是实现难度其实并不高，一个拦截器加一个Token工具类就行了。

4.2 统一响应结构：给后端加一层"通讯协议"

很多新手写接口时，返回值的类型很随意。有的返回一个Map，有的直接返回一个实体类，有的干脆返回一个字符串。这种混乱的接口风格，到了答辩展示时问题不大，但一旦老师打开源码随便看一个Controller，就会立刻给你的代码规范性扣分。

正确的做法是定义一个统一响应类Result<T>，里面包含三个字段：code（状态码，如200成功、500失败、401未登录）、msg（描述信息）、data（实际的数据）。所有接口的返回值都用这个类型包装。Controller层看起来都是一致的：返回Result.success(data)或者Result.error("参数错误")。

配合统一响应类的，还要有全局异常处理器。用@RestControllerAdvice加@ExceptionHandler声明式地把业务异常、参数校验异常、系统异常分别处理。这么做最大的好处是，哪怕代码里某一个地方出了问题，响应给前端的依然是一个格式正确的JSON，而不是莫名其妙的一堆堆栈信息。这在答辩时如果老师故意输入一个异常参数，你能看到前端页面友好地提示"参数错误"而不是白屏，那就是一个很有说服力的演示瞬间。

4.3 参数校验、XSS和SQL注入：让代码看起来像"企业级"

这几个点是我认为全项目中"投入产出比"最高的部分。你不用付出太多工作量，但能在代码评审时极大提升好感。

参数校验，最简单的做法是在实体类字段上加@NotBlank、@NotNull等校验注解，Controller层接口参数用@Valid触发校验。比如添加分类时分类名称不能为空、添加文章时标题不能为空。这样你就不用写一堆if (xxx == null) return Result.error()了。注意，你需要在配置里打开校验的快速失败模式，否则默认情况下会一次性返回所有校验错误，信息会很长，不好看。

SQL注入的预防在MyBatis-Plus框架下其实已经比较安全，只要你不是拼字符串SQL，而是用QueryWrapper或者#{}占位符，基本就安全了。这里要提醒的是，写自定义SQL时一定用#{field}，不要用${field}。${}是字符串直接拼接，如果那个字段是从前端传过来的，就存在被注入的风险。答辩时主动说出"我使用的是预编译参数占位符来防止SQL注入"，这句话很轻但很加分。

XSS（跨站脚本攻击）这一块，个人博客因为要展示富文本内容，其实是存在XSS风险的。最简单的一层防护是在全局配置里做一个HTTP请求体的XSS过滤，把<script>标签等危险关键字替换掉。你不用完全实现一个工业级过滤器，但只要代码里出现了拦截器做非法字符过滤这个动作，就能体现出你考虑过安全问题，这在学生项目里已经属于加分项了。

5. 从源码到交付：部署、论文与演示视频的实操路线

5.1 打包部署：让系统在别人电脑上也能跑起来

一个毕设项目如果只在自己电脑上能跑，到了评审机器上就各种报错，那是最糟糕的情况。我给你一套我认为最稳妥的部署交付路线。

先保证项目能用Maven正常打包。在项目根目录执行mvn clean package -DskipTests，如果构建成功，target目录下会出现一个xxx.jar文件。这里要提醒一个常见的启动报错：很多同学的配置文件里把数据库密码写成了自己电脑上的密码，或者把localhost写死了，别人拿到源码换成自己的数据库后，连接直接失败。正确做法是把数据库连接配置单独放在application.yml里，并且在部署说明文档中清楚地列出需要修改的配置项，同时附上一个blog.sql数据库脚本。

数据库脚本怎么写有讲究。你要用Navicat或者命令行把整个数据库结构导出来，但不仅仅是结构——如果有初始数据，比如默认管理员账号、预置的几个分类和几篇文章示例，也要导进去。这样别人启动后第一眼看到的就是一个有数据的系统，而不是一个空的后台，体验会好非常多。

如果有余力，我建议做一个启动校验的功能：系统启动时自动检查数据库里的表是否创建，如果没有则自动执行建表语句。这个可以用Spring的初始化脚本配置或者Flyway来做。虽然会多一点工作量，但这会让你的部署说明显得非常专业，推荐有余力的同学尝试。

5.2 论文写作：各章节该写什么，篇幅如何分配

毕设论文（LW）是一个很多人头疼的环节，但其实它有非常清晰的套路。以这个题目为例，我的建议是章节结构大致这样安排。

绪论部分写选题背景、国内外研究现状、研究内容和目标，篇幅控制在全文的10%左右，千万别把背景写成"随着互联网的发展"这种空话，而是从"个人写作者需要一个自我表达阵地"这个具体场景切入。相关技术介绍部分写Spring Boot、MyBatis-Plus、MySQL、Thymeleaf等内容，注意不要写成教科书级别的概念堆砌，而要写你在这个项目里用到了这些技术的哪些特性。需求分析部分要写功能性需求和非功能性需求，可以画用例图，关键是把自己系统里的三种角色场景写清楚：游客可以浏览文章和评论，注册用户可以发表评论和管理自己的文章，管理员可以管理分类、文章和所有评论。

系统设计部分是论文的重头戏，要占30%的篇幅。这里包括系统总体架构图、功能模块设计、数据库表设计（每一张表的字段含义都要写），还有关键业务流程图。系统实现部分用截图加代码片段来展示每个模块的实现效果。测试部分要写功能测试和性能测试，性能测试可以简单用JMeter跑一个并发请求页面，得到一个响应时间数据，这个数据比空口说"系统很稳定"有说服力一百倍。最后是总结与展望，简单写一下项目过程中遇到的问题和不足就行了，不要长篇大论。

5.3 演示视频录制：顺序、话术与避雷

演示视频是很多人随便拿手机录一屏就交差的内容，但这其实是性价比非常高的交付物。录制顺序我强烈建议按照"项目介绍、系统演示、难点讲解"三步走。

录制之前先写一个三分钟到五分钟的脚本。第一步用一段画外音介绍项目的核心理念和技术栈，同时展示项目结构。第二步进入功能演示：先演示前台页面，展示文章列表、文章详情、评论展示；然后切换后台，演示登录、文章管理、分类管理、评论管理。每一步操作前先说你要做什么，再操作。第三步回到代码中，展示一个你自认为写得最好的模块，比如分页查询或者评论层级组装，用几十秒时间讲一下核心逻辑。这一套流程下来，一个让老师耳目一新的演示视频就成了。

避雷点也在这里说三个。第一，录制前一定要关掉自己电脑上不必要的弹窗和通知，录到一半来一个微信弹窗，非常不专业。第二，录制前先跑一遍完整流程，保证所有接口都正常响应，别在录制时遇到一个500错误然后陷入长时间的Debug。第三，画面分辨率建议1080p以上，不要太糊，也不要录完整个聊天记录或者桌面壁纸太花，干净的专业壁纸或者纯色背景。

6. 答辩前的自查清单与我踩过的坑

6.1 用一张功能测试表提前堵住评审的嘴

答辩之前，我强烈建议你准备一张功能测试表，把所有功能点列出来，每个功能点后面写上测试步骤和预期结果。这既是给自己做回归测试，也是给演示环节准备的行动清单。

比如文章管理模块，测试用例可以是：登录后点击新增文章，填写标题、选择分类、录入富文本内容，保存后前台列表能展示新文章；修改文章标题后，前台详情页能显示新标题；删除一篇文章后，前台列表不再展示这篇文章，但后台回收站里能恢复。再比如评论模块：文章详情页中已登录用户能发表评论，未登录用户点击评论时提示跳转登录页面；后台可以把某条不当评论屏蔽，前台不再出现。

这张表在答辩现场的价值在于：老师问"你这个系统做过测试吗"，你可以直接展示这张表而不是含糊地说"我测过了"。而且你在做演示时，按表上的顺序走，逻辑清晰不绕弯，观感好很多。这张表也能直接复制进论文的测试章节，一鱼两吃。

6.2 高频答辩问题的标准答法

我结合带毕设的经验，把常见的答辩问题归纳成几类，答案你可以提前准备好。

"为什么选Spring Boot而不用SSM？"标准的答法是：Spring Boot在SSM的基础上实现了自动配置，简化了项目搭建和部署流程，让我把更多精力放在业务逻辑而不是繁琐的XML配置上，而且Spring Boot生态里的starter机制能很方便地集成第三方组件。"你的系统安全性是怎么考虑的？"答法：密码使用加密存储，访问接口时通过拦截器校验登录状态，数据集操作使用参数化查询预防SQL注入，输入内容做了XSS过滤。"评论的无限级回复是怎么实现的？"答法：用parent_id加reply_user_id两个字段记录评论之间的父子关系和被回复人，查询时先查顶级评论再批量查子评论，内存中组装树形结构，避免循环查库。

在回答问题时有一个通用策略：不要背答案，要结合你自己的代码细节来讲。哪怕讲得结巴一些，只要你能指到具体的类名和方法名，就让老师相信这个项目是你自己一步步写出来的。

6.3 A同学的真实翻车案例与补救方案

最后分享一个我印象很深的案例。有个A同学，项目功能做得其实不错，但偏偏在答辩前把数据库密码改掉了，自己忘了，评委现场让他二次运行系统时，项目直接启动不起来，场面一度很难看。后来他花了十分钟才想起来密码是什么，但这个卡壳已经严重影响了整体印象。

这个案例的教训有两个。第一，答辩前的最后一晚，一定要把整个项目交付流程完整走一遍：从解压一个新的源码压缩包开始，按部署说明一步步操作，直到系统正常跑起来。这一步能暴露几乎所有环境相关问题。第二，准备一个应急手册，里面记录常见启动异常的前三部排查法：端口占用、数据库连接失败、Redis未启动。虽然个人博客项目不强制用Redis，但如果你用了，就一定要把它写进部署说明并确保评委那台机器能正常启动Redis，否则这又是下一个翻车点。

如果演示环节真的出问题了，我的建议是不要慌张，也不要疯狂刷新页面浪费时间，而是坦诚地说一句"这里我先把后端日志打开看一下，可能是本地环境配置问题"。然后冷静地打开日志，用一两分钟定位并解释问题。这种表达比那种死撑着说"我刚才还在跑"要可信得多，很多评委反而会认可你解决问题的能力。

这个题目做完这么久，我比较大的感受是：个人博客系统虽然不考验高并发和分布式技术，但非常考验工程落地的完整度。一个功能全部可用、代码结构清晰、部署说明细致、论文写得像样的项目，远比一个技术概念堆砌得满天飞但实际跑不起来的项目更受认可。你把这篇文章里提到的每一块都补齐，这个毕设不仅不会翻车，还会成为你简历上很有说服力的一块项目经历。