JavaWeb社交媒体平台毕设实战：技术选型与数据库设计全解析

每年毕设季，我都能收到大量类似的问题：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，很多同学第一反应是JSP+Servlet写一堆Java代码拼HTML，报错一堆乱码，页面丑得拿不出手。这确实是早期JavaWeb开发的典型画面，但不是我推荐的技术路线。在这个项目里我们用Spring Boot整合JavaWeb的传统能力，页面层换成了Thymeleaf模板引擎，代码简洁度、可维护性和演示观感都提升了好几个档次。

2.1 主流技术栈与简历价值的权衡

先看主流选择。做JavaWeb毕设，现在通常有三条路线：

从答辩和实际能力提升两个角度来看，我推荐第三条路线。这里有一个很关键的经验：毕设是大学阶段少有的、可以不用受课程大纲限制的自由技术实践项目，你完全可以用更贴近企业实际开发的技术栈来做。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官方starter，SQL写在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`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 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 ThreadLocal<User> 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可以被彩虹表破解，加盐后每个用户盐值不同"这个道理，已经超过绝大多数同学了。如果项目里想做得更专业，直接用BCryptPasswordEncoder，Spring 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?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false 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 高频报错排查清单

我把带过的人中最高频报错列成一张表，照着查基本能解决：

最后再单独提一个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之间是如何配合的。改完这一个功能，你对整个项目的掌控感会瞬间不一样，答辩时老师问起任何一个功能，你都能自信地回答"这个我看过，核心逻辑在这里"。

从我带过的学生情况来看，凡是这么做了的，答辩基本都顺利通过，而且老师评价普遍不错。反过来，那些拿到源码只跑了一下、连数据库脚本都没执行过的同学，即使代码本身能跑，一旦被追问细节就露馅了。源码只是起点，真正把它变成自己的东西，永远是从你亲手改掉第一行代码开始的。