整理这套“海滨学院班级回忆录设计与实现信息管理系统”的源码，我把它完整盘了一遍，从数据库表设计、后端接口，到前端页面和本地部署，整个过程走下来比想象中顺畅，也踩了几个不大不小的坑。先说结论：如果你需要一个能直接跑起来、前后端分离、数据落库的班级回忆录Web应用，这套SpringBoot+Vue+MySQL的方案确实是个很省心的起点。它面向的场景很简单——班级毕业之后，散落在群相册、朋友圈、聊天记录里的照片和文字太零散了，一个班级需要一块能把大家共同回忆集中存放、按时间线翻阅、还能让同学留言互动的阵地。适合拿来做毕业设计、课程设计，也适合想自学前后端分离开发的同学拿来当参照工程。
下面我把这套系统从设计到落地的完整过程整理出来。内容会覆盖模块拆解、表结构设计、后端关键实现、前端页面组织，以及本地一键运行的部署细节和避坑记录，基本照着操作就能把你手里的源码跑明白，再往上加功能也有清晰的思路。
1. 项目整体设计与核心模块拆解
1.1 需求拆解：一台回忆录，要装下哪些东西
班级回忆录这个切入点，核心不是“做一个好看的首页”，而是把回忆内容组织起来。回忆录要装下的东西其实就四类：人、内容、事件、互动。
人是参与主体。一个班级系统必须有用户体系，区分管理员、班委和普通同学。管理员负责整体维护，班委可以审核内容或者管理分类，普通同学则是主要内容贡献者。
内容是核心资产。这里包括回忆文章、照片、留言。文章可以写某次班会、某位老师的金句，也可以写个人和班级的故事；照片是班级回忆里最直观的部分，按相册或时间归类；留言墙则提供一个相对轻量的表达空间。
事件是时间轴。班级四年（或三年）发生了什么大事，录取、迎新、军训、运动会、毕业照，这些事件串起来才是一本真正的“回忆录”，而不是一堆零散碎片的堆砌。
互动是温度。没有点赞和评论，回忆录就只是一个静态存档，缺少让同学再次连接起来的气氛。所以评论和点赞功能也应该是系统的一等公民。
1.2 技术选型：为什么这套组合最适合拿来就跑
这套系统用的是SpringBoot后端、Vue前端、MySQL数据库，我觉得选型是相当务实的，理由有三点。
第一，SpringBoot天生适合做这种单体业务系统。自动配置大幅减少了中间件环境的折腾，内置Tomcat意味着后端环境装好JDK就能直接启动。对于一个班级回忆录场景，完全不需要拆微服务，把业务写在清晰的分层里就够了。
第二，Vue作为前端框架足够灵活，也足够主流。Vue的组件化开发让页面结构非常清楚，路由管理、状态管理、HTTP请求这些都有成熟配套，对刚接触前后端分离的开发者来说，这个技术栈能找到的参考案例是最多的。
第三，MySQL存这种强结构化数据最合适。用户信息、文章、评论、点赞，都是明确的表结构，用SQL查起来效率高，事务也可靠。相比NoSQL，MySQL更适合这个场景下的数据一致性维护。
这套组合还守住了“可直接运行”的底线——不需要额外引入Redis、不需要搭建消息队列，一个MySQL加一个Node环境，前后端就能全部拉起。
1.3 功能清单：先把边界画清楚
具体落地的功能模块，我整理成了下面这张表：
| 模块 | 核心功能 | 使用角色 |
|---|---|---|
| 用户管理 | 注册、登录、个人信息维护、头像上传 | 全部用户 |
| 回忆文章 | 发布、编辑、删除、分类与标签、列表分页 | 全部用户（删除限本人或管理员） |
| 评论与点赞 | 文章评论、点赞、取消点赞 | 登录用户 |
| 照片墙 | 相册分类、照片上传、图片预览 | 登录用户（上传），所有人可看 |
| 留言墙 | 发布留言、留言展示 | 登录用户 |
| 班级时光轴 | 按年份/学期记录班级大事、时间线展示 | 管理员/班委维护，所有人可看 |
| 统计面板 | 文章数、照片数、留言数、用户数概览 | 所有人可见 |
这套边界画得很克制，没有加一些“看起来高大上但很难跑完”的功能，比如全文搜索引擎、分布式文件存储。边界清晰的好处是开发量可控，出问题也好定位。
2. 数据库设计与表结构关系
2.1 整体表设计：先把收纳盒分好
数据库设计是这套系统最关键的环节。我的习惯是先想清楚数据从哪里来、会被谁以什么方式查，再动手建表。这张回忆录系统一共规划了这么几张表：
sys_user（用户表）：账号、密码、昵称、头像、角色、注册时间。article（回忆文章表）：标题、正文、封面图、分类、标签、作者、发布时间。photo（照片表）：所属相册、图片URL、上传者、上传时间、图片描述。album（相册表）：相册名称、封面、创建者。comment（评论表）：所属文章、评论内容、评论人、评论时间。like_record（点赞表）：所属文章、点赞人、点赞时间。message（留言表）：留言内容、留言人、留言时间、是否展示。timeline_event（时光轴事件表）：事件标题、事件描述、发生时间、创建人。
把这些表看成家里收纳杂物的盒子，每个盒子只放一类东西。用户表就是通讯录，文章表是日记本，照片表是相册，留言表是便签墙。盒子之间通过外键或逻辑外键联系成一张网。
2.2 核心建表SQL与字段设计
先看用户表，它要做的事很明确——登录认证和展示身份信息。密码字段必须存加密后的密文，这里使用BCrypt加密。角色字段我是直接用字符串存储的，简单直接，查询高效，不像角色表加权限表那么重，适合这个体量的系统。
CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录账号', `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `role` varchar(20) NOT NULL DEFAULT 'STUDENT' COMMENT '角色：ADMIN/MONITOR/STUDENT', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';然后是回忆文章表，这是整个系统的内容核心。一个关键设计是author_id字段用于关联用户，后续查询“我发布的回忆”“某个人的回忆”全靠它。状态字段status我留了0和1两个值，0表示草稿，1表示已发布，以后要加审核功能只要再加一个值就行。
CREATE TABLE `article` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `title` varchar(100) NOT NULL, `content` text NOT NULL, `cover_url` varchar(255) DEFAULT NULL, `author_id` bigint(20) NOT NULL, `category_id` bigint(20) DEFAULT NULL, `tags` varchar(200) DEFAULT NULL COMMENT '逗号分隔标签', `status` tinyint(4) NOT NULL DEFAULT '1', `view_count` int(11) NOT NULL DEFAULT '0', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_author_time` (`author_id`, `create_time`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='回忆文章表';像comment、photo、message、like_record这几张表结构都比较直接，核心就是谁、在什么时候、对什么内容、做了什么事。比如点赞表，我特意给article_id和user_id加了一个唯一索引，目的就是让同一人对同一篇文章只能点赞一次，这一条约束能从数据库层面防住重复点赞。
2.3 关系与查询路径：从页面反推SQL
设计完表，要习惯从页面反推查询SQL。看一眼前端要展示的场景，数据库设计合不合理就很清楚了。
首页的“最新回忆列表”，要展示文章标题、封面、作者昵称、创建时间。对应SQL要关联article和sys_user两张表取昵称：
SELECT a.id, a.title, a.cover_url, a.create_time, u.nickname FROM article a LEFT JOIN sys_user u ON a.author_id = u.id WHERE a.status = 1 ORDER BY a.create_time DESC LIMIT 10;文章详情页除了文章本身，还要展示评论区。评论列表的SQL会关联用户表取评论者的头像和昵称，然后按时间升序排列，模拟一个自然对话的顺序。文章点击量则是每次进入详情页时对view_count字段做增量。
时光轴页面比较特殊，它不按照文章的发布时间排序，而是按照timeline_event表中的event_date字段排序。所以设计时光轴表时，event_date一定要单独建索引，否则班级回忆录累计到几百条事件之后，页面会明显变慢。
3. 后端核心实现细节
3.1 后端工程分层与包结构
拿到源码以后，肉眼第一件事就是看包结构。这套系统的后端分层很常规，但规范得很舒服：
controller：接收HTTP请求、参数校验、调用service、返回统一结果。service：业务逻辑层，处理具体的业务规则。mapper：数据访问层，用MyBatis或MyBatis-Plus操作数据库。entity：实体类，和数据库表字段一一对应。common：通用返回结果、异常处理、常量。config：配置类，比如跨域配置、拦截器注册。
这种分层逻辑其实就是厨房分工。Controller是前台服务员，只负责端菜收菜单；Service是厨师，负责炒菜，不管菜怎么端上桌；Mapper是后厨采购员，只管找食材。这样一来，改前端接口结构不会动业务代码，改业务逻辑也不会碰SQL，排错的时候特别省时间。
3.2 登录鉴权与权限控制
登录功能是后端最容易出问题的点，也是系统安全的门户。这套系统采用的是JWT（JSON Web Token）方案。
登录流程是这样的：用户提交用户名和密码，后端用BCrypt验证密码，验证通过后生成一个包含用户ID和角色的JWT，返回给前端。前端把JWT存储在本地，之后每一次HTTP请求都在请求头里带上Authorization: Bearer <token>，后端通过拦截器解析token，就能知道当前用户是谁、是什么角色。
拦截器的核心逻辑，我简化成下面的样子：
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (request.getMethod().equals("OPTIONS")) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); try { Claims claims = JwtUtil.parseToken(token); request.setAttribute("userId", claims.get("userId")); request.setAttribute("role", claims.get("role")); return true; } catch (Exception e) { throw new BusinessException("登录已过期，请重新登录"); } } throw new BusinessException("未登录"); }这里踩过的一个坑是预检请求。前后端分离之后，前端浏览器在发起跨域POST请求前，会先发一个OPTIONS请求试探。如果拦截器把OPTIONS请求也拦了，前端跨域请求统统失败。所以拦截器里第一步就要判断OPTIONS请求直接放行，配合后端的跨域配置一起使用，才能保证联调顺滑。
3.3 核心业务接口的实现逻辑
几张核心表的接口设计，基本遵循RESTful风格，同时结合页面需要做适当简化。
文章发布的Controller长这样：
@PostMapping("/article") public Result<?> createArticle(@RequestBody ArticleDTO dto, HttpServletRequest request) { Long userId = (Long) request.getAttribute("userId"); return Result.success(articleService.createArticle(dto, userId)); }在Service层真正干活的逻辑，核心就几步：将DTO转成实体，补上作者ID和默认状态，然后插入数据库。如果上传了封面图，封面URL是提前生成好的，直接存进去。文章发布成功后，系统还会更新该用户的发布统计。
点赞接口有个细节值得单独说。点击“点赞”按钮后，前端会调/article/{id}/like这个接口。后端先去like_record表查记录：如果存在记录，就删除这条点赞并给文章点赞数减一，相当于“取消点赞”；如果不存在记录，就新增一条并加一。因为这个表有article_id和user_id的唯一索引，即使前端疯狂点击导致并发请求同时到达，数据库层面也只会有一条记录插入成功，天然防住了重复点赞。
3.4 图片上传与静态资源映射
图片上传是照片墙和头像功能的核心。后端的实现思路是：接收MultipartFile文件，校验文件类型和大小限制，生成一个UUID文件名防止重名，保存到本地配置的上传目录，然后返回一个可以访问的URL地址。
这里最容易犯的错是保存成功后前端图片打不开。原因在于SpringBoot默认只处理静态资源目录里的文件，你上传到的是自定义目录，框架并不知道怎么把它暴露给外部访问。所以必须在配置类里加一个映射：
@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Value("${file.upload-dir}") private String uploadDir; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadDir + "/"); } }这样配置后，上传图片的访问地址就是http://localhost:8080/upload/xxxx.jpg。这个路径要小心写，file:前缀不能丢，路径末尾的斜杠也不能少，本地Windows和Linux目录格式还不一样，都是容易踩的细节。
4. 前端页面设计与Vue集成
4.1 前端工程结构与路由设计
前端是Vue工程，入口后主要页面包括登录注册页、首页、回忆列表页、文章详情页、照片墙页、留言墙页、时光轴页和个人中心页。路由设计如下：
/login：登录注册。/home：首页，展示最新回忆、统计概览。/article：回忆文章列表，支持分类筛选。/article/:id：文章详情，包括评论和点赞。/album：照片墙。/time-line：班级时光轴。/message：留言墙。/profile：个人中心。
前端工程目录里，views目录放页面级组件，components目录放可复用的子组件，比如文章卡片、图片懒加载组件、分页条。api目录下按业务模块拆分接口请求，utils目录放axios封装和登录状态工具。这种结构看一遍就能理解整个项目脉络。
4.2 核心页面组件拆解
时光轴页面是整个回忆录最有趣味的页面。我实现的思路是：后端一次性返回按年份分组的事件数据，前端用时间轴样式展示，左侧是年份，右侧是该年份下的事件卡片，卡片上显示日期、标题和短描述。Vue组件里其实就是一个v-for嵌套遍历，外层遍历年份，内层遍历事件，配合CSS实现左右交替的效果。
照片墙页面同样不难，核心在一个grid栅格布局。照片卡片用懒加载指令处理，只有滚动到可视区域才真正请求图片地址，否则一个班级传几百张照片，首屏加载会卡到怀疑人生。前端图片预览用的lightbox模式，点击小图弹出大图，支持左右切换。
我挑了一个比较能说明Vue核心用法的片段，文章列表组件里的渲染逻辑：
<template> <div class="article-list"> <article-card v-for="item in articles" :key="item.id" :article="item" @click="goDetail(item.id)" /> </div> </template> <script setup> import { ref, onMounted } from 'vue' import { getArticleList } from '@/api/article' import ArticleCard from '@/components/ArticleCard.vue' const articles = ref([]) const loadArticles = async () => { const res = await getArticleList({ page: 1, pageSize: 10 }) articles.value = res.data.records } onMounted(loadArticles) </script>组件化开发的核心就是像搭积木一样，把文章卡片抽成独立组件，列表页用、个人中心用、搜索结果页也用，改样式只改一处，全局生效。
4.3 前后端联调细节：axios封装、Token携带与跨域
前端联调部分最值得写清楚的是axios的统一封装。我习惯建一个request.js，统一配置baseURL、超时时间、请求拦截器和响应拦截器。
baseURL不要写死成localhost:8080，而应该用环境变量控制，在.env.development里写一份，在.env.production里写另一份。这样以后部署到服务器，只需要改环境变量，不需要动业务代码。
请求拦截器里统一把token塞进请求头：
service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config })响应拦截器里统一处理错误，尤其是后端的401状态码。遇到401说明token失效或者未登录，直接跳转回登录页。这一步能避免每一处接口调用都重复写“没登录怎么办”的判断逻辑。
跨域问题则是在后端解决的。配置类里加上CORS映射，允许指定来源的请求访问后端接口，同时允许携带凭证：
registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true);开发环境其实还有另一种更稳妥的方案：前端的Vite配置devServer代理，把/api前缀的请求代理到后端8080端口，浏览器全程只和前端域名打交道，就没有跨域问题了。源码里这两种思路都有体现，二选一即可。
5. 本地一键运行的部署流程与避坑清单
5.1 环境版本推荐
这套系统要本地跑起来，环境准备工作其实很简单，但版本搭配不要乱来。我实测下来比较稳的组合是：
| 组件 | 推荐版本 | 备注 |
|---|---|---|
| JDK | 1.8 或 11 | 我用的JDK 8，兼容性最好 |
| Maven | 3.6 以上 | 用来打包后端 |
| MySQL | 5.7 或 8.0 | 8.0需要注意驱动名变化 |
| Node.js | 16 或 18 | 16最稳，20+可能遇到编译兼容问题 |
| npm | 随Node自带 | 安装前端依赖用 |
后端是一个标准Maven工程，前端是一个Vue工程，目录结构一般在压缩包里都分好了，一个叫backend，一个叫frontend，打开就能看到。
5.2 数据库初始化与后端启动
第一步是创建数据库并导入SQL脚本。我习惯在MySQL命令行里执行：
mysql -u root -p create database class_memory default character set utf8mb4; use class_memory; source /path/to/sql/class_memory.sql;导入SQL后，改成后端的数据源配置。在application.yml里，把URL、用户名、密码改成自己本地的实际值。这里强烈建议URL后面加上characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai，特别是MySQL 8.0，不加时区参数会直接报时间错误。
spring: datasource: url: jdbc:mysql://localhost:3306/class_memory?characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver然后在项目根目录执行：
mvn clean package -DskipTests java -jar target/class-memory-server.jar看到Started Application日志输出，后端就就跑起来了，默认端口是8080。
5.3 前端启动与联调
前端启动前先把依赖装上：
npm install装依赖的时候容易遇到速度慢的问题，可以先把镜像源切换成国内源，过程不展开。装完之后：
npm run dev启动成功会给你一个本地访问地址，默认是http://localhost:5173，浏览器打开就是系统首页。
如果前端页面打开后接口数据加载不出来，优先看两个地方：第一个是浏览器的DevTools Network面板，看请求是404还是500；第二个是检查前端的代理配置，看看/api请求是否符合已经配置的转发规则。大部分联调失败问题都出现在这两个环节。
5.4 高频报错与解决清单
部署过程中我整理了几个比较有代表性的报错，直接做成速查列表：
- 后端启动报
Access denied for user 'root'@'localhost'，说明数据库用户名或密码写错了，检查application.yml。 - 启动报
Unknown database 'class_memory'，说明数据库没有创建成功，回SQL那一步检查脚本执行情况。 - 前端
npm install报opensslErrorStack，多半是Node版本太高和某些依赖不兼容，切换到Node 16即可。 - 前端页面能打开但是登录接口404，大概率是前端代理路径和后端
context-path没对上，需要确认代理转发路径。 - 上传图片成功但照片墙加载不出来，检查后端的静态资源映射是否配置正确，以及上传目录是否真实存在。
这些坑看起来琐碎，但每一个都是实际项目中高频出现的。把版本环境先用对，后面能省掉一大堆排查时间。
6. 常见问题速查与未来扩展思路
6.1 常见问题速查表
我把在这个项目上被反复问到的问题整理成了一张速查表，方便源码拿到手后照着排查：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 登录接口返回500 | 数据库密码加密方式不匹配 | 确认用户表里存的密码是BCrypt生成的密文 |
| 所有接口返回401 | 前端请求未携带token | 检查axios请求拦截器是否正常写入Authorization |
| 评论功能报“文章不存在” | 文章状态为草稿或已删除 | 查询时增加status过滤 |
| 数据中文乱码 | 数据库连接串缺少编码参数 | URL加上characterEncoding=utf8 |
| 运行一段时间后图片加载慢 | 原图未做压缩处理 | 扩展方向：接入图片压缩或对象存储 |
| 时光轴事件顺序混乱 | 排序字段用错 | 确认按照event_date排序而不是create_time |
6.2 从“能跑”到“好用”的扩展方向
这套系统跑起来之后，它的意义不是停留在“能运行”这个层面，而是给后续的功能扩展留足了空间。我结合实操经验列几个值得尝试的方向。
第一个方向是备份与导出。班级回忆录本质是情感资料沉淀，数据不能被单个数据库绑架。最常见的扩展是做一个“回忆册导出”功能，把文章和照片打包成PDF或HTML文件下载。这个功能用后端生成PDF或者HTML模板就能实现，前端加一个导出按钮即可。
第二个方向是评论审核和内容安全。当系统真的给班级所有人使用后，评论和留言需要有人管理。给管理员加一个“内容审核”页面，comment表和message表加一个status字段，0待审核1已通过2已拒绝，这比直接删数据温柔得多，也更符合班级管理的使用习惯。
第三个方向是视觉体验升级。照片墙目前处理正常图片没问题，但如果同学们上传的都是手机原图，动辄几MB，加载速度会受影响。把图片上传环节加上压缩，或者迁移到对象存储，是提升体验的一个很直接的路径。
第四个方向是数据统计和纪念日提醒。毕业多年后，系统里最温馨的功能其实是“今天是入学十周年”这类提醒。做一个定时任务，读取timeline_event里的事件日期，匹配到当前日期就推送一条提醒。这个功能技术难度不高，但情感价值极高。
这次把整套流程完整跑下来，我最深的体会是：这类系统的成败，往往不取决于用了多前沿的技术，而在于表结构是否清爽、接口约定是否统一、环境版本是否对齐。班级回忆录这种项目，真正的“技术含量”恰恰藏在照片上传路径、Token拦截顺序、分页查询效率这些看起来不起眼的细节里。如果这个项目后续要继续迭代，我优先想加的还是回忆册导出和评论审核，因为这两件事能让它从一个“演示项目”变成一个真正可以被班级长久使用的工具。如果你正在拿这套源码做改造，欢迎在实际操作中多关注我上面列的那几个坑，省下来的时间够你再写一个功能模块了。
