每年毕设季我都能收到大量类似的问题JavaWeb方向的题目怎么选选了之后怎么把代码跑起来数据库表怎么设计才不会答辩一问就崩尤其“社交媒体平台”这个题目几乎年年都有学生选但真正能交出一份完整源码加文档、还能当场调试运行的项目并不多。原因不在于题目本身难而在于很多人把它想得太复杂或者太简单。这篇就是基于一个实际交付过的项目来说说从选题逻辑、技术选型、表结构设计到IDEA里的运行配置、答辩准备完整过一遍基于JavaWeb的社交媒体平台到底该怎么落地。先交代一下这个项目的背景。它是一套完整交付的毕设工程包包含源码、开题报告、系统文档、PPT以及配套的远程调试运行和讲解服务。技术路线是JavaWeb体系下非常经典的一条线面向前端展示用模板引擎渲染页面后端处理业务逻辑MySQL做持久化。对有基础但没实战经验的同学来说这套仕路是性价比最高的选择。下面我就按我的实际开发顺序把每个环节的取舍和坑点都讲清楚。1. 毕设选题为什么社交媒体平台是个巧妙的题很多同学一开始会纠结社交媒体平台是不是太大了微博、朋友圈、论坛、即时通讯哪一个光是听起来就很有工作量。实际上毕设级别的社交媒体平台不需要覆盖这么多东西我们只需要抓住用户发布内容、用户之间互动、内容按时间流展示这条核心主线就能把项目做成一个完整闭环同时还能在答辩时展现出需求分析、权限控制、数据建模、性能优化等各方面的能力。1.1 它天然覆盖了JavaWeb的核心考点你看毕设评分表会发现无论是本科还是专科评审老师看重的几乎都是同一组能力点用户登录注册、Session保持、CRUD操作、数据库表设计、页面数据展示、简单的增删改查权限控制。社交媒体平台恰好把这几个点全部覆盖了。用户模块能考察注册登录和密码加密动态模块能考察内容发布和列表分页评论点赞能考察关联查询和事务关注功能能考察复杂一点的SQL和关系表设计。换句话说这个题目不大不小正好卡在既有技术含量、又能在规定时间内完成的位置上。如果你选一个图书管理系统功能太单薄不够做系统设计和答辩展示如果你选一个仿微博全套系统那工作量又失控了。社交媒体平台是中间档能展示的东西恰好是老师想看到的。1.2 演示效果好答辩不容易冷场还有一个很现实的考量因素答辩现场演示。社交媒体平台的界面本身就是用户熟悉的形态——注册登录、刷动态、看评论、看到其他用户的个人主页。不需要复杂的初始化数据来营造效果老师一看到界面就能理解系统是干什么的。而且这类项目天然自带多角色属性你可以演示普通用户操作再切管理员后台审核内容和查看统计数据整个演示流程非常流畅。此外这类项目做扩展也很方便。如果导师要求你加点什么东西你可以加WebSocket做消息推送加Redis做热门动态缓存加推荐算法思路做Feed流排序。这些都属于加分项不影响主体功能的前提下可进可退给答辩多留了余量。1.3 交付物的角度源码和文档怎么配比更合理这个项目最终交付时源码和文档的比例大概是七比三。源码里我建议至少包含一个可以直接导入IDEA运行的Maven工程以及一份初始化SQL脚本文档部分至少要有开题报告、需求分析、概要设计、数据库设计、详细设计、测试报告和总结展望。这样的结构不是随便定的而是照着答辩评分表的评分点倒推出来的。文档不需要写得像学术论文但每个章节都要有实质内容尤其数据库设计部分字段注释、表关系说明越详细越好因为老师翻文档第一个就会看这里。2. 技术选型的底层逻辑JavaWeb不等于老掉牙的JSP说到JavaWeb很多同学第一反应是JSPServlet写一堆Java代码拼HTML报错一堆乱码页面丑得拿不出手。这确实是早期JavaWeb开发的典型画面但不是我推荐的技术路线。在这个项目里我们用Spring Boot整合JavaWeb的传统能力页面层换成了Thymeleaf模板引擎代码简洁度、可维护性和演示观感都提升了好几个档次。2.1 主流技术栈与简历价值的权衡先看主流选择。做JavaWeb毕设现在通常有三条路线技术路线开发效率演示效果学习成本与课程契合度纯Servlet JSP低较差低高SSM框架 JSP中一般中中Spring Boot MyBatis Thymeleaf高较好中中从答辩和实际能力提升两个角度来看我推荐第三条路线。这里有一个很关键的经验毕设是大学阶段少有的、可以不用受课程大纲限制的自由技术实践项目你完全可以用更贴近企业实际开发的技术栈来做。Spring Boot本身就是一个轻量级JavaWeb容器它把原来Servlet那一堆配置全部自动化了你在IDEA里点击运行就能启动一个内嵌Tomcat不需要单独下载Tomcat、手动部署war包这对毕设来说省掉了最折腾的一环。2.2 Thymeleaf到底比JSP好在哪里页面渲染层是用Thymeleaf还是走前后端分离加Vue这是很多同学纠结的地方。我的结论是毕设项目老老实实用Thymeleaf。前后端分离确实更现代化但代价是你必须同时维护两个工程要处理跨域请求要把接口文档写好答辩时要同时打开前端服务和后端服务一旦端口冲突或者接口地址写错现场演示就卡壳了。Thymeleaf是服务端渲染模式动态数据直接填充到网页模板里返回给浏览器。它最大的优势是Java开发可以直接在一个工程里完成全部工作页面中还能直接用th:each、th:if这些语法遍历数据和控制显示写起来就像写普通HTML加JSTL标签一样自然。对没有前端工程化经验的同学来说这个学习曲线是最平缓的。2.3 依赖清单和版本搭配项目使用Maven管理依赖核心依赖如下。版本不是越新越好建议跟着稳定配对走这些年我配过上百个环境下面这套组合的兼容性几乎没有问题Spring Boot 2.7.x内置Tomcat自动配置生态老化解决各种历史坑文档也全MyBatis 2.3.x对应Spring Boot官方starterSQL写在Mapper XML里便于展示数据库功底MySQL Connector 8.0.x对应MySQL 5.7和8.0都兼容Thymeleaf由Spring Boot官方starter管理版本Lombok精简实体类代码答辩时讲实体字段更清晰Druid连接池可选但生产级连接池写在文档里比默认的Hikari更有话说这里需要补充一个我在实际中反复强调的点Spring Boot版本要用2.7而不是刚发布的3.x。3.x基线是JakartaEE和Java 17很多学校机房和老师的电脑还是Java 8环境用2.7.x加JDK8兼容性最好。你到答辩现场换一台机器也能跑起来这是非常实在的考虑。3. 功能模块与页面结构先画清边界再动手写代码很多同学拿到这个题目后第一件事就是建数据库、写代码结果写了一半发现功能互相纠缠登录没做好就做发布发布没做完又开始做评论。正确的做法是先做功能地图把系统的角色、每个角色能做什么、页面之间如何跳转全部理清楚再开始动手。3.1 系统角色与功能权限矩阵这个平台设计了普通用户和管理员两个角色。普通用户是核心角色能做的事包括注册登录、浏览公共动态列表、发布新动态支持图片、删除自己的动态、对他人动态评论、给动态点赞或取消点赞、关注其他用户、查看关注列表和粉丝列表、查看个人主页和自己的动态列表。管理员是辅助角色负责登录后台、管理普通用户列表禁用或启用账号、管理动态内容删除违规内容、查看系统基础统计数据。权限控制不搞复杂用最简单的登录拦截加角色判断。普通用户功能全部要求登录后访问未登录只能看到登录页和注册页管理员后台在登录时根据用户角色字段做拦截非管理员直接跳转回首页。这一步在Spring Boot里用HandlerInterceptor实现非常方便下面是代码骨架public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); User user (User) session.getAttribute(loginUser); if (user null) { response.sendRedirect(/login); return false; } return true; } }在WebConfig里把拦截器注册掉注意区分哪些路径需要拦截、哪些路径放行Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns(/**) .excludePathPatterns(/, /login, /register, /css/**, /js/**, /images/**, /upload/**); }3.2 页面清单和跳转关系整个前端页面数量控制在12个以内比较合理注册页、登录页、首页动态广场、动态详情页、发布动态页、个人主页、我的关注页、我的粉丝页、个人信息编辑页、消息通知页、管理员登录页、后台管理页。每个页面主题统一导航栏固定包含Logo、首页、发布按钮、个人头像下拉菜单这样演示时视觉上不会显得碎片化。动态详情页是一个容易忽略但很重要的页面。它不能只展示一条动态和它的评论还要展示评论分页、点赞按钮、返回列表的入口。我在实际项目中看到不少同学把动态详情页做成了静态页面评论区写死答辩时被老师一点就露馅了。详情页必须真实地从数据库按动态ID查出动态正文、作者信息、评论列表并且评论提交后刷新列表。3.3 用户故事优先的开发顺序代码落地不要按先用户后动态再评论的教科书顺序来写按用户故事来写效率更高。第一个用户故事是访客注册登录完成用户表和Session逻辑第二个用户故事是登录用户发布一条动态并看到它出现在自己主页完成动态表和首页列表第三个故事是用户A评论用户B的动态完成评论表和关联查询以此类推。每完成一个故事系统就是一个可运行的小闭环方便你随时停下来测试而不会积压一堆半成品代码。4. 数据库设计核心表结构和索引策略是答辩的加分点数据库设计是我在评审和改代码时最看重的一块。社交媒体平台涉及的核心实体包括用户、动态、评论、点赞、关注、私信、通知对应到数据库里至少需要这几张核心表。我把建表脚本拆成四个部分来讲结构清晰了后面写代码会非常省力。4.1 用户表与动态表用户表字段不多但有几个细节需要注意。密码字段用password存储加盐哈希值而不是明文nickname允许为空但建议注册时就让用户填avatar存储默认头像路径bio是个人简介。删除策略这里做的是逻辑删除也就是用一个status字段控制账号启用和禁用为管理员后台禁用用户做准备而不是直接物理删除记录。动态表类似用is_deleted标记用户自己删除的动态保留记录便于追查。CREATE TABLE t_user ( id bigint(20) NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录用户名, password varchar(100) NOT NULL COMMENT 加密后的密码, nickname varchar(50) DEFAULT NULL COMMENT 昵称, avatar varchar(255) DEFAULT NULL COMMENT 头像路径, bio varchar(200) DEFAULT NULL COMMENT 个人简介, role tinyint(4) NOT NULL DEFAULT 1 COMMENT 角色:1用户,2管理员, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态:1正常,0禁用, create_time datetime NOT NULL COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT用户表;动态表的核心字段包括user_id作者、content正文、image图片路径单图或逗号分隔多图都用这一个字段存、like_count点赞数冗余字段、create_time发布时间。这里我刻意做了一个存储上很有效的决定点赞数用冗余字段而不是每次都COUNT统计。虽然存在并发下数字可能短期不准的问题但毕设项目里这个取舍能明显减少SQL复杂度而且演示性能表现更好。4.2 互动关系三张表评论、点赞、关注评论表围绕谁评论了谁的哪条动态设计三个核心外键字段加评论内容和时间。点赞表用联合唯一索引保证同一用户对同一动态只能点赞一次这是防止重复点赞的关键关注表用联合唯一索引保证关注关系唯一。这三张表看起来结构简单但往往是整个项目里关联查询最多的地方。CREATE TABLE t_like ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 点赞用户ID, post_id bigint(20) NOT NULL COMMENT 动态ID, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_user_post (user_id, post_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT点赞表; CREATE TABLE t_follow ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 关注者ID, follow_user_id bigint(20) NOT NULL COMMENT 被关注者ID, create_time datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_user_follow (user_id, follow_user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT关注关系表;这里要强调一个我在教学时经常说的点很多同学写关联查询时喜欢在表上加物理外键约束这是没有必要的。项目中的一对多关系通过user_id等逻辑外键来维护应用程序代码保证数据一致性数据库层面的外键索引会拖慢插入性能而且后期维护很麻烦。你不加物理外键但在答辩时能讲清楚逻辑关系和索引设计老师反而会觉得你有实际工程经验。4.3 初始化数据与时间字段的处理为了让项目下载下来就能看到效果初始化脚本要预置几个测试账号、几条带图片的动态和一些点赞评论数据。管理员账号和普通用户账号都用明文初始密码示例标识比如admin/123456代码里用统一的工具类做MD5加盐加密后写入。这里有个小坑MySQL 5.7和8.0对datetime字段的默认值处理不同你最好在实体类和SQL中都显式声明时间格式避免数据库默认值导致插入报错。使用create_time字段上手动传new Date()的方式最安全不依赖数据库的DEFAULT CURRENT_TIMESTAMP特性。5. 核心功能实现细节那些不起眼但决定成败的代码技术选型和表结构都是地基真正决定项目质量的是几个核心功能的实现细节。我从这个项目里挑出四个最典型、也最容易被老师追问的点来讲这几个点做到了项目就是功能完整而不是勉强能跑。5.1 登录状态保持从Session到拦截器这个项目用的是Session方案。登录成功后把用户对象塞进Session后续请求通过拦截器从Session取出用户并绑定到ThreadLocal这样在Service层任何地方都能拿到当前用户ID不用每次把用户ID当参数传来传去。很多同学第一次写社交项目时会把userId从一个方法传到另一个方法代码里满是参数看着都痛苦。用ThreadLocal优雅很多public class UserContext { private static final ThreadLocalUser HOLDER new ThreadLocal(); public static void set(User user) { HOLDER.set(user); } public static User get() { return HOLDER.get(); } public static Long getUserId() { return get() null ? null : get().getId(); } public static void clear() { HOLDER.remove(); } }拦截器在放行之前把用户写入ThreadLocal请求结束后在afterCompletion里clear掉防止内存泄漏。这套小手段在毕设里不算必考但在简历上写ThreadLocal上下文绝对比Session存取听起来正式得多。5.2 密码加密别再用明文了我见过太多毕设项目的用户表密码列存了一串明文这几乎是答辩公开处刑现场。正确做法是使用MD5再加盐。具体流程是注册时每个用户生成一个随机盐值比如UUID.randomUUID().toString().substring(0, 8)然后拼接密码和盐值做MD5运算最终把盐值:加密结果存进密码字段。校验时从库里取出盐值用同样的方式再算一遍对比结果。不要嫌MD5不够安全毕设阶段能说清楚不加盐的MD5可以被彩虹表破解加盐后每个用户盐值不同这个道理已经超过绝大多数同学了。如果项目里想做得更专业直接用BCryptPasswordEncoderSpring Security里的密码加密器一行代码搞定加盐和校验答辩还能顺便说一句这是行业标准做法。5.3 Feed流查询关注动态的关联SQL社交平台最核心的查询是我关注的用户发布的最新动态列表。这个SQL用子查询可以写但实际项目里更常用的是JOIN。比如查询当前用户关注的人的所有动态SELECT p.id, p.user_id, p.content, p.image, p.create_time, u.nickname, u.avatar FROM t_post p INNER JOIN t_user u ON p.user_id u.id WHERE p.user_id IN ( SELECT follow_user_id FROM t_follow WHERE user_id #{userId} ) AND p.is_deleted 0 ORDER BY p.create_time DESC LIMIT #{offset}, #{pageSize}这条SQL在答辩时能讲清楚两个点为什么要JOIN用户表因为动态列表要展示作者昵称头像为什么要子查询查关注列表因为它天然表达了A对B的关注这种语义。分页用LIMIT简单可靠不需要引入PageHelper也完全够跑。实际项目里如果你希望翻页体验更好还可以加一个简单的游标分页用create_time做锚点不过毕设用LIMIT完全没问题答辩讲起来不慌。5.4 点赞的并发幂等唯一索引兜底点赞功能看似简单仔细想想里面有坑。用户狂点多次点赞按钮如果前端没有做防抖后端就会执行多次插入导致同一个用户对同一条动态产生多条点赞记录。解决思路有两个层面前端点击后立即置灰按钮这是体验兜底后端在点赞表上建uk_user_post联合唯一索引然后插入使用INSERT IGNORE利用数据库约束天然拦截重复数据。Override public boolean like(Long userId, Long postId) { try { likeMapper.insertIgnore(userId, postId); return true; } catch (DuplicateKeyException e) { return false; // 已经点过赞 } }同样的思路用在取消赞上先查点赞记录是否存在存在再删除并减掉冗余计数。事务上给likeCount的更新和点赞记录的插入加上Transactional保证要么都成功要么都失败。这是我说的细节加分项面试或答辩时聊这个逻辑会非常出彩因为很多学生根本没想到重复点击这个问题。6. IDEA里把这个项目跑起来的完整过程拿到源码之后最怕的事情就是双击打开就开始报错。这里我不讲文档里那些假大空的步骤直接讲拿到这个zip包后你在IDEA里从导入到能打开登录页面的每一步顺便把最常踩的坑一起排掉。6.1 环境对齐先把版本统一才能谈运行运行JavaWeb项目的环境组合模板是JDK 8加Maven 3.6及以上加MySQL 5.7或8.0加IDEA 2021之后的版本。JDK和Maven、Node都不一样Maven不需要单独装IDEA内置了可用的Maven插件但建议你自己下载一个Maven 3.6以上版本并在IDEA里指定原因很简单内置的Maven有时会在中央仓库下载依赖时卡死自己指定一个配置了国内镜像的settings.xml下载速度能快十倍。数据库连接串是大多数人第一次跑失败的重灾区。Spring Boot 2.7配合MySQL 8.0时URL里必须带上时区参数否则启动报错。最稳妥的配置如下spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/social_platform?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: root password: 你的数据库密码注意MySQL的root密码不要写在文档里让所有人都知道拿到项目后改成自己的再启动。MySQL这边要做的准备只有两步用source命令导入初始化SQL脚本或者在Navicat里打开SQL文件执行一遍然后确认表都建出来了。6.2 从zip到运行标准导入流程IDEA导入Maven工程有一个最不容易出错的路径打开IDEA选择Open定位到解压后的目录选中pom.xml文件IDEA会认出这是一个Maven工程并开始下载依赖。千万不要用New Project向导去新建然后硬拷贝代码那样会引入一堆莫名其妙的目录结构问题。依赖下载完成后做三件事刷新Maven项目让依赖完全下载确认Project Structure里的Project SDK是JDK 8确认Language Level是8。这三步确认完直接运行入口类类名一般是类似SocialApplication里面有SpringBootApplication。启动日志滚动起来后看到Tomcat started on port 8080打开浏览器输入http://localhost:8080能看到登录页就说明项目跑通了。6.3 高频报错排查清单我把带过的人中最高频报错列成一张表照着查基本能解决报错场景根本原因解决办法启动报数据库连接失败URL参数缺失或密码错误检查yml配置中的url时区参数和password端口被占用上次运行没有干净停掉netstat -ano | findstr 8080查PID后结束或改server.port页面中文全部乱码MySQL建表字符集或连接编码不对确认建表SQL是utf8mb4URL带characterEncodingutf8上传图片404本地存储路径和静态映射没配对检查WebConfig的addResourceHandlers映射是否正确依赖大量标红Maven仓库未下载完执行mvn clean install或反复点击刷新按钮最后再单独提一个IDEA运行JavaWeb项目时经常出现的问题有些人运行后发现登录/注册的静态资源加载不出来页面光秃秃没有CSS。原因通常是拦截器把/css/**路径也拦截了或者静态资源路径和Controller的/login路径冲突。检查拦截器的excludePathPatterns里是否放行了静态目录这是我在整理配置时特意写进去的细节。6.4 数据初始化和管理员入口第一次跑通后你看到的是预置的测试数据。初始管理员账号一般是admin加初始密码登录后顶部导航会多出一个后台管理的入口。如果初始化脚本没跑干净比如出现大家都用同一个盐值加密的情况可以用更新SQL批量重新生成密码或者干脆删库重导一遍初始化脚本。数据库这种东西毕设阶段大胆删删不坏才是好事反正有SQL脚本可以随时恢复这个认知比任何技术细节都重要。7. 文档写作和答辩演示让代码的功劳被老师看见项目代码只是毕业设计的一半另一半是文档和答辩。我要说一个很多人不愿意接受的事实两个代码水平差不多的项目文档和演示准备做得好的那个最终成绩能高出两三个档。因为老师对你的代码最多运行几分钟但文档他可能翻几遍答辩现场你的表达才是最终印象。7.1 文档如何按评分点组织一套合格的毕设文档章节顺序应该是开题报告、需求分析、系统总体设计、数据库设计、功能模块详细设计、系统测试、总结展望。其中数据库设计是最容易拉开差距的部分要有ER图可以用PlantUML或者Draw.io画不要用Word画框看齐、表清单、核心表字段说明以及表与表之间关系的文字描述。论文里还要有一个专门的技术选型小节讲清楚为什么用Spring Boot而不是JSP为什么用MyBatis而不是纯JDBC。不要只写Spring Boot能够快速开发这种套话要写对比结论比如传统Servlet需要手动配置web.xml和Servlet映射一旦过滤器多了很难维护Spring Boot自动配置大大降低了集成成本。这种话老师读起来就知道你是真做过对比不是从百度文库复制的。7.2 演示脚本三条主线走完十分钟答辩演示要在十分钟内把系统亮点全部展示出来。我建议准备三套走查脚本。第一套是用户全流程注册一个新账号看用户名查重登录后发布一条带图片的动态回到首页看时间线出现新动态点开茶品详情页评论一条回到动态列表确认评论数更新。第二套是关系功能去另一个用户的个人主页关注他回到首页看他的动态已经出现在你的Feed流里。第三套是管理后台切换管理员账号进后台把刚才测试发布的动态禁用再到前台确认这条动态消失。三套脚本覆盖了系统90%的功能模块。演示时先做一遍类型的操作再用讲解配合PPT回顾数据库表结构和关键SQL设计。特别提醒演示前一定要关掉所有无关程序浏览器提前打开登录页数据库服务确认在运行。现场翻车的最常见原因不是代码有bug而是演示前没有做环境自检。7.3 高频答辩问题与应答思路老师基于这个题目最常问的问题就那么几个为什么选用Spring Boot和Thymeleaf的组合登录状态如何保持、如何防止未登录访问受限资源数据库中的点赞表为什么用联合唯一索引如果用户基数变大Feed流怎么优化自己项目的安全问题怎么考虑每个问题都准备一个三句话以内的核心应答再准备一到两句扩展。尤其最后一个问题哪怕你只答出来密码用MD5加盐存储、管理员和普通用户有独立权限、前台页面做了输入校验就足以证明你完整考虑过安全性这在毕设答辩里已经是相当亮眼的表现。另外如果想把这套项目再往前推一步有几个低成本高收益的扩展方向。一是把点赞数和评论数接入Redis缓存定期同步回MySQL这个几乎是社交平台的标配二是用拦截器加接口幂等性校验防止表单重复提交三是给评论表加分页解决热门动态下评论列表过长的问题四是对图片上传增加类型、大小的校验防止有人上传超大文件打爆服务器磁盘。任何一个方向在文档的改进和展望章节里都能撑起一页纸的讨论。8. 拿到源码之后的三件事很多同学付费买完源码或者从学长那里拷贝完工程第一件事就是激动地打开运行然后埋在报错里出不来。这里我给你一个建议拿到源码之后先不要碰代码按顺序做三件事。第一把数据库脚本执行起来打开Navicat或者命令行逐张表看一遍字段和注释。你不需要理解每一行代码但你需要知道系统里到底存了哪些数据这是你后面所有操作的基础。第二把项目启动起来按照上文的演示脚本把前端页面完整走一遍把自己当作一个普通用户去点击、刷新、查看数据库里的变化。你会发现很多代码里的谜题在页面上一操作就通了。第三找一个小功能动手改一下。比如把系统名字改成你自己起的名字把首页的导航文案改掉或者给评论加一个简单的删除功能。这一步不是装饰而是让你真正进入项目内部在改代码的过程中理解Spring Boot Controller、Service、Mapper之间是如何配合的。改完这一个功能你对整个项目的掌控感会瞬间不一样答辩时老师问起任何一个功能你都能自信地回答这个我看过核心逻辑在这里。从我带过的学生情况来看凡是这么做了的答辩基本都顺利通过而且老师评价普遍不错。反过来那些拿到源码只跑了一下、连数据库脚本都没执行过的同学即使代码本身能跑一旦被追问细节就露馅了。源码只是起点真正把它变成自己的东西永远是从你亲手改掉第一行代码开始的。