基于SpringBoot+Vue的情绪宣泄平台全栈开发实战

1. “情绪宣泄平台”到底是个什么项目：先看清需求全貌

做这个项目之前，我建议你先别急着写代码。很多同学拿到“基于SpringBoot + Vue情绪宣泄平台”这个题目，第一反应就是去GitHub上搜同款，或者直接打开IDEA开始建工程。我见过太多人折腾两周后回来问我：“为什么我的项目评委看一眼就说不完整？”原因几乎都一样——根本没说清楚这个平台到底是给谁用的、要解决什么问题。

先把这个题目拆开来看。“情绪宣泄”四个字听起来很抽象，但落到系统功能上，其实就是一件事：让用户有一个安全、私密、可记录的情绪表达空间。常见的功能形态包括：情绪日记（用户记录当天的心情和事件）、匿名倾诉（用户发帖子，可以匿名或者用昵称）、心理小贴士（平台推送一些情绪调节的内容）、情绪统计（用图表展示用户一段时间内的情绪变化趋势）、以及后台管理（管理员可以管理帖子、用户、标签等）。

技术栈方面，题目点明了SpringBoot + Vue，这两个词背后的意思就是：前后端分离架构、RESTful API交互、MySQL存数据。SpringBoot负责提供接口，Vue负责页面渲染和用户交互，两者通过JSON格式的数据进行通信。这个架构是目前主流Web应用的标配，也是企业里最常用的一套组合。

这个项目适合谁做？两个人群最合适：一是计算机相关专业需要做毕业设计或课程设计的学生，这个题目难度中等偏上，既能展示后端接口设计能力，又能体现前端界面交互能力，比纯“图书管理系统”或“学生管理系统”的区分度高很多；二是想系统学习SpringBoot + Vue全栈开发流程的初学者，通过一个完整项目把所有环节串起来，比零散看教程有效得多。

我为什么强调先看清需求全貌？因为等你真正动工之后，需求是否清晰直接决定了数据库表怎么建、接口怎么设计、页面怎么划分。很多人做到一半发现“啊，原来还要管理员登录功能”，然后回头改数据库，一改就是几十张表联动，心态直接崩掉。所以第一步，把需求清单列出来，划清楚用户角色和核心场景。下面是我在实际设计时采用的方案，你可以直接参考。

2. 数据库设计：整个项目的“承重墙”，多数人栽在这里

2.1 先想清楚：这个系统里有哪些角色，各自干什么

情绪宣泄平台的角色划分不复杂，但容易漏。核心角色有两个：普通用户和管理员。普通用户的典型操作是：注册登录、写情绪日记、发匿名倾诉帖、浏览和评论别人的帖子、查看自己的情绪统计。管理员的典型操作是：登录后台、管理用户（禁用/启用账号）、管理帖子（审核、删除违规内容）、管理情绪标签、查看系统数据概览。

数据库设计的第一步就是把角色和操作映射成表。我见过不少人的设计只有一个user表和一个post表，然后管理员功能硬塞进user表里用一个role字段区分。这种做法在小demo里勉强能跑，但一旦涉及权限控制、数据隔离，就会写得非常别扭。

我的建议是至少设计以下这些表：

这个设计的好处是：角色清晰、数据边界明确、功能扩展空间大。比如你后续想加一个“心理测评”功能，只需要新增一张assessment表和对应的结果表，完全不影响已有结构。

2.2 核心表的字段设计：少一个字段，功能就塌一角

我重点说三个最容易出问题的地方。

第一，user表的password字段设计。如果你直接存明文密码，那这个项目别说答辩，自己这关都过不去。正确做法是用BCrypt加密，Spring Security里自带BCryptPasswordEncoder，存进去的是一段哈希字符串。数据库里字段长度要留够，BCrypt加密结果长度是60个字符左右，所以password字段建议设为varchar(100)，别设成varchar(20)这种长度，不然加密后的字符串存不进去。

第二，emotion_record表的多维度设计。我这里用了一个emotion_score字段表示情绪评分，比如1到5分，5分代表非常开心。这个字段看起来简单，但它是后面情绪统计图表的数据基础。如果你想做得更有分析价值，可以再加几个字段，比如emotion_type（情绪类型）、trigger_event（触发事件），这样就能回答“用户因为什么事件产生了什么情绪”这个问题。不过要控制复杂度，毕设项目做到emotion_type + emotion_score已经足够。

第三，post表的匿名设计。这里有个细节：如果用户选择匿名发帖，那么页面上不显示用户名，但数据库里仍然要存user_id，否则管理员无法追溯。所以post表要有一个is_anonymous字段，前端根据这个字段决定显示“匿名用户”还是真实昵称。查询的时候也要注意，给前端返回的数据不能直接暴露user_id对应的用户名，需要在接口层面做一层脱敏处理。

2.3 建表SQL的实操笔记：字符集、索引、外键一坑一个准

直接给你一份我实际用过的建表脚本片段，里面有几个细节值得注意：

CREATE TABLE `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 '头像地址', `role` tinyint(1) DEFAULT '0' COMMENT '角色：0-普通用户 1-管理员', `status` tinyint(1) DEFAULT '1' COMMENT '状态：1-正常 0-禁用', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='用户表';

三个实际踩过的坑：

• 字符集必须用utf8mb4而不是utf8。utf8在MySQL里只能存3个字节的字符，遇到生僻字或某些特殊符号会直接报错或变成乱码。这个项目涉及情绪表达，用户可能会输入各种表情符号，utf8mb4才能完整支持。
• 用户名一定要加唯一索引。不然用户注册时你还要先查一遍再插入，多一次数据库交互不说，并发请求下还会出现重复用户名。
• 外键能不用就不用。我并不是说外键不好，而是在SpringBoot + MyBatis-Plus的项目里，外键约束反而会给后续的数据操作添乱。比如你要删除一个用户，如果他有帖子、评论、情绪记录，外键约束会阻止你删除，你得手动一个个清理关联数据。用逻辑外键（也就是在代码里控制关联关系）比物理外键灵活得多。

建表顺序也有讲究：先建user表，再建emotion_dict表（因为它是基础字典数据），然后建emotion_record、post、comment、feedback这些业务表。如果你建表顺序搞反了，后面的表关联user表时会报“表不存在”的错误。

3. 后端SpringBoot实现：从Entity到Controller的一条完整链路

3.1 项目结构规划：别把什么东西都塞进Controller

SpringBoot项目的代码结构直接决定了你后面写代码的心情。我建议按模块分包，而不是按技术层分包。什么意思？就是不要把所有Controller放一个包、所有Service放一个包，而是按业务模块划分，比如user模块、emotion模块、post模块、comment模块、feedback模块，每个模块内部再分Controller、Service、Mapper。

这种分包方式的好处是：当你改情绪记录相关功能时，只需要在emotion包下面改动，不用在十几个包之间来回跳。对于毕设项目来说，这种结构的可读性比“按技术层分包”高得多，评委一看就知道你懂工程化组织。

下面是我推荐的项目结构：

com.example.emotion ├── controller # 各业务模块的Controller层 │ ├── UserController.java │ ├── EmotionRecordController.java │ ├── PostController.java │ └── CommentController.java ├── service # Service接口 │ └── impl # Service实现类 ├── mapper # MyBatis-Plus的Mapper接口 ├── entity # 数据库实体类 ├── dto # 前端交互的数据传输对象 ├── config # 配置类（跨域、拦截器、WebMvc配置） ├── common # 公共类（统一返回结果、异常处理、工具类） └── EmotionApplication.java

注意entity和dto要分开。实体类对应数据库表的字段，dto对应前端实际需要的数据。很多初学者图省事，直接拿实体类返回给前端。这在单表操作时问题不大，但一旦你需要“帖子列表附带评论数量”这种聚合数据，实体类就装不下了，要么加无关字段，要么写乱七八糟的嵌套对象。养成用dto的习惯，后面你会感谢自己。

3.2 统一返回结果：一个Result类省掉一半的前后端联调痛苦

前后端分离项目里，接口返回的数据格式如果不统一，前端要针对每个接口单独处理返回结构，运维和联调都会很痛苦。我强烈建议你在一开始就封装一个统一的返回结果类。

我的做法是这样的：

@Data public class Result<T> { private Integer code; // 状态码：200成功，400业务错误，401未登录，500系统错误 private String message; // 提示信息 private T data; // 返回数据 public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(400); result.setMessage(message); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }

所有Controller方法的返回值都包装成Result，前端统一通过response.data.code判断请求是否成功、通过response.data.data取业务数据。这个习惯一旦养成，不光这个项目，你以后写的所有前后端分离项目都会受益。

3.3 核心接口设计：情绪记录和匿名帖子的实现思路

情绪记录模块的核心接口是“新增情绪记录”和“查询情绪趋势”。新增接口的逻辑很简单：接收用户提交的情绪类型、内容和评分，写入emotion_record表。但这里有一个业务细节值得思考——要不要允许用户一天记录多次？

我的设计是允许的。因为一个人的情绪在同一天内可能起伏很大，早上焦虑、晚上开心，这很正常。所以emotion_record表不设置“一天只能一条”的约束，而是用record_date字段记录具体日期时间。查询情绪趋势的时候，你可以按日期分组，取当天所有记录的平均分，这样展示在图表上会更加平滑。

查询情绪趋势的SQL用MyBatis-Plus的QueryWrapper就能实现：

public List<EmotionTrendVO> getEmotionTrend(Long userId, Integer days) { // 计算起始日期 LocalDate startDate = LocalDate.now().minusDays(days - 1); LambdaQueryWrapper<EmotionRecord> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(EmotionRecord::getUserId, userId) .ge(EmotionRecord::getRecordDate, startDate) .orderByAsc(EmotionRecord::getRecordDate); List<EmotionRecord> records = emotionRecordMapper.selectList(wrapper); // 按日期分组，计算每日平均情绪评分 Map<LocalDate, Double> avgScoreMap = records.stream() .collect(Collectors.groupingBy( r -> r.getRecordDate().toLocalDate(), Collectors.averagingDouble(EmotionRecord::getEmotionScore) )); // 组装连续日期的数据，没有记录的日子补0 List<EmotionTrendVO> trendList = new ArrayList<>(); for (int i = 0; i < days; i++) { LocalDate date = startDate.plusDays(i); EmotionTrendVO vo = new EmotionTrendVO(); vo.setDate(date.toString()); vo.setScore(avgScoreMap.getOrDefault(date, 0.0)); trendList.add(vo); } return trendList; }

这里有个关键细节：不要只返回有记录的数据，要返回连续日期的数据。比如用户查最近7天的趋势，如果第3天和第5天没有记录，前端图表上直接断掉会很丑。用上面的方式把缺失日期的score补0，前端用折线图展示时，趋势线是连续的，视觉效果和专业度都会高很多。

匿名帖子的接口设计也有讲究。发帖接口接收的dto里包含title、content、isAnonymous三个字段，isAnonymous为true时，返回给前端的数据里userInfo字段置为空，显示“匿名用户”。但数据库里user_id还是要存的，这样管理员在后台能看到是谁发的。这里需要在接口层面做脱敏，不能在SQL层面直接不查user_id然后就结束了——因为评论表关联帖子时可能还需要发帖人信息。

3.4 SpringBoot配置的进阶玩法：Banner、版本选择、跨域配置

标题相关热词里出现了“springboot banner生成器”，这个确实是个容易增加演示趣味性的点。SpringBoot启动时会打印一个ASCII艺术字符的Banner，默认是Spring的Logo。你可以用patorjk.com的Text to ASCII Art Generator生成自定义文字，把生成的内容保存到src/main/resources/banner.txt里，启动时就会显示你自定义的图案。做毕设演示的时候，启动日志里打出自己名字的ASCII艺术字，那种仪式感还是很加分的。

版本选择上，我建议SpringBoot 2.7.x，不要追高用3.x。为什么？因为3.x是基于Jakarta EE的，很多老教程、老依赖的包名都变了，比如javax改成jakarta，你按2.x的教程写代码会报包名不存在的错误。对于毕设项目来说，稳定大于一切。2.7.x版本非常成熟，网上资料多，遇到问题一搜就有答案，完全没有必要在版本兼容性上给自己挖坑。

跨域配置是前后端分离项目必须处理的问题。开发环境下，Vue跑在8080端口，SpringBoot跑在8081端口，浏览器会拦截跨域请求。解决办法是在SpringBoot里配置WebMvcConfigurer：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

这个配置允许所有来源的跨域请求，开发环境完全够用。生产环境部署时，为了安全可以把allowedOriginPatterns改成具体的域名。注意allowCredentials(true)要让Vue端axios请求也配置withCredentials: true，不然携带Cookie的请求会被拒绝，这个坑我踩过。

4. 前端Vue实现：页面不只是好看，还要好用

4.1 路由设计：页面结构要有逻辑，不能想起一个加一个

Vue项目里，路由配置直接反映了整个系统的页面结构。我建议你先把路由规划好再动手写页面，不要写了一堆组件之后再回来配路由，那样你根本记不住自己写到哪里了。

这个项目的路由规划参考：

/ → 首页（平台介绍、情绪小贴士） /login → 登录页 /register → 注册页 /home → 用户主页（需要登录） /home/dashboard → 情绪概览（统计图表、今日情绪） /home/record → 写情绪日记 /home/posts → 倾诉广场（帖子列表） /home/posts/:id → 帖子详情 /home/profile → 个人中心（修改资料、查看我的记录） /admin → 管理后台（需要管理员角色） /admin/users → 用户管理 /admin/posts → 帖子管理 /admin/dashboard → 数据概览

路由要注意两个点：一是用路由守卫控制访问权限，未登录用户访问/home下的页面时自动跳转到/login；访问/admin下的页面时，除了要登录，还要检查当前用户的role是否为管理员，不是就直接跳回首页并提示“无权限访问”。二是在页面跳转时，用beforeEach配合meta字段统一处理标题变化，这样浏览器标签页上的标题能跟着页面变化。

4.2 状态管理：用Vuex还是Pinia，数据到底放在哪

Vue项目的状态管理，老项目用Vuex，新项目推荐Pinia。Pinia是Vue官方推荐的新一代状态管理库，API更简洁，类型支持更好，Vue 3 + Pinia是现在的主流组合。如果你用的是Vue 3，直接上Pinia；如果因为某些原因还在用Vue 2，那只能选Vuex。

状态管理在这个项目里主要解决两类数据：一是用户登录信息，登录成功后把token和用户基本信息存到store里，这样页面跳转时不会丢失登录状态；二是全局的配置数据，比如情绪字典（emotion_dict表里维护的情绪标签列表），登录后请求一次存到store里，后续写情绪日记、展示情绪选项时直接从store读取，不用每次下拉框打开都发起一次接口请求。

一个注意点：不要把后端接口返回的大列表数据都塞进store。store里的数据应该是对全局有意义的、需要跨页面共享的数据。像帖子列表这种数据，让页面自己管理请求和响应就行，存到store里反而增加维护成本。这是很多人容易走偏的地方，一看到“状态管理”就什么都往里塞。

4.3 页面组件拆解：情绪统计图表和M3U8视频播放

如果首页的情绪趋势用图表展示，前端需要引入一个图表库。推荐ECharts，中文文档全面，社区活跃，图表类型丰富。在Vue 3里用vue-echarts封装一下很方便。

这里有个实际操作建议：ECharts的按需引入。完整引入的包体积非常大，页面加载会明显变慢。你可以只在需要图表的地方引入要用到的组件模块，比如LineChart、GridComponent、TooltipComponent、CanvasRenderer。这样打包体积能少一半以上。

import { use } from "echarts/core"; import { CanvasRenderer } from "echarts/renderers"; import { LineChart } from "echarts/charts"; import { GridComponent, TooltipComponent, LegendComponent } from "echarts/components"; import VChart from "vue-echarts"; use([CanvasRenderer, LineChart, GridComponent, TooltipComponent, LegendComponent]);

还有一个热词是“vue播放m3u8”。如果你的情绪宣泄平台里包含一些放松视频、冥想音频的资源，可能会用到m3u8格式的视频流。Vue播放m3u8最常用的方案是video.js配合videojs-contrib-hls插件。不过要注意，videojs-contrib-hls这个插件已经停止维护了，新项目建议直接用hls.js配合原生video标签。

import Hls from "hls.js"; const video = document.getElementById("video"); if (Hls.isSupported()) { const hls = new Hls(); hls.loadSource("你的m3u8地址"); hls.attachMedia(video); hls.on(Hls.Events.MANIFEST_PARSED, () => { video.play(); }); }

这里需要提醒一下：m3u8通常需要在后端配置跨域请求头，否则前端拿不到视频流。如果你本地测试时视频黑屏，优先检查接口的跨域配置是否包含了video标签发起的请求。这个问题的排查思路放到后面第6章细说。

4.4 组件库选择：Element Plus还是Ant Design Vue

热词里出现了“ant design vue”，说明很多人关注这个。情绪宣泄平台这种管理系统型的界面，用现成的组件库是最高效的。国内用得最多的两个是Element Plus和Ant Design Vue。

我的看法是：Vue 3项目优先选Element Plus。理由很简单：Element Plus就是Vue生态的原生组件库，跟Vue 3配合最自然，文档清晰，组件齐全，社区里踩坑经验多。Ant Design Vue虽然也不错，但它本身是React版Ant Design的移植，有些组件的使用习惯还是带React的影子，在Vue项目里有点水土不服，而且版本迭代时破坏性更新相对频繁。

组件库引入方式建议全量引入。毕设项目规模不大，全量引入带来的体积增加可以接受，而且全量引入省去了按需引入的配置步骤，开发效率更高。如果之后要优化性能，再用unplugin-vue-components做按需引入也不迟。

5. 数据库初始化与测试数据：让Demo演示更出彩

5.1 一份能直接跑的SQL脚本应该包含什么

很多同学打开SQL文件一执行，直接两三百行DDL就完事了，把表建好就丢给评委。这样做有个问题：评委打开你的系统，登录页面是空的，需要自己注册一个账号才能体验功能。如果注册流程里还要求邮箱验证码之类的，评委大概率不会自己折腾。你的系统在演示时应该是一眼就能看到核心功能状态的。

所以我强烈建议SQL脚本里除了建表语句，还要包含以下内容：

• 默认管理员账号：插入一条username为admin、密码为BCrypt加密后字符串的记录，同时在文档里注明密码是123456（或者其他你能记住的）。
• 演示用普通用户账号：插入一条测试用户，绑定几个情绪记录和帖子数据。
• 情绪字典数据：插入开心、难过、焦虑、平静、愤怒、惊喜等情绪标签，排序字段要规划好。
• 每个模块至少3到5条演示数据：3条情绪记录覆盖不同的日期和情绪类型，3篇帖子覆盖“普通发布”和“匿名发布”两种场景，每条帖子带几条评论。

这样设置的效果是：评委用admin登录后台，能看到完整的数据统计和管理列表；用演示用户登录前台，直接就有情绪趋势图表、帖子列表可以点击查看。整个系统的功能完整性一眼可见。

5.2 测试数据的“真实性”策略：别拍脑袋编

测试数据不能随便填。比如emotion_record表里，如果你填的是“2024年1月1日到2024年1月7日”每天一条，那么用户查看最近7天趋势时图表是满的，但如果你填的是上个月的数据，这个图表就是空的。

我的做法是：用脚本生成最近30天或最近7天的连续数据。比如最近的记录都是今天，往前推每一天都有数据，情绪评分在3到5之间波动，其中穿插一两条2分的数据表示某天心情不好。这样的数据在图表上看起来是一条有起伏的曲线，而不是一条平直的线，视觉效果好得多。

帖子内容也别用“测试帖子内容123”这种。你可以写几条贴近主题的内容，比如“今天工作压力很大，感觉快撑不住了，上来倾诉一下”“终于通过了考试，开心！”，每篇帖子配一两条相关评论。这种数据在答辩演示时能很好地让评委理解平台定位——“啊，原来是让人倾诉和缓解情绪的”。

5.3 数据库脚本导出的姿势：IDEA导出脚本的正确操作

热词里有“idea导出数据库脚本”，这个操作其实很实用。当你把表建好、测试数据也填好之后，需要导出SQL脚本作为交付物之一。这里有个关键操作：导出时要勾选“包含Drop表语句”和“包含数据”两个选项。

用IDEA操作的话，路径是：右侧Database面板 → 右键点击要导出的数据库或表 → Export with mysqldump，或者用Export to file的方式。导出时注意选择导出整个数据库（包含建库语句），这样别人拿到脚本后，直接执行就能把数据库完整还原，不需要手动新建库再导入。

一个小坑：如果你是先用Navicat或者命令行建的表，IDEA的数据库面板可能没刷新出来。一定要先点击Database面板上的刷新按钮，同步最新的表结构，再执行导出操作。不然导出的脚本可能缺少最新创建的表。

6. 前后端联调与部署：踩坑最多的一个阶段

6.1 axios封装：拦截器里做登录状态管理和错误提示

前端请求后端接口，强烈建议封装一个axios实例，统一处理baseURL、请求头、响应拦截。

import axios from 'axios'; import { ElMessage } from 'element-plus'; import router from '../router'; const request = axios.create({ baseURL: '/api', // 开发时通过Vite代理转发 timeout: 10000 }); // 请求拦截器：在请求头里带上token request.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = token; } return config; }); // 响应拦截器：统一处理错误 request.interceptors.response.use( response => { const res = response.data; if (res.code === 401) { // 未登录或token过期，跳转到登录页 localStorage.removeItem('token'); router.push('/login'); return Promise.reject(new Error('未登录')); } if (res.code !== 200) { ElMessage.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } return res; }, error => { ElMessage.error(error.message || '网络异常'); return Promise.reject(error); } );

这里要特别注意：不是所有请求都要带token。比如登录和注册接口，在发送时用户还没登录，如果统一在请求拦截器里强制加上token，它会拿一个空值去设置请求头，虽然多数情况下没影响，但后端如果严格校验Authorization头格式，就可能报错。我的做法是在拦截器里做个判断，如果token不存在就不设置Authorization字段。

6.2 前后端联调的经典问题清单

做前后端联调时，以下问题出现的频率最高，提前知道能节省大量排查时间：

问题一：接口通了但数据是undefined。通常是字段名不匹配。后端用驼峰命名userName，前端用下划线user_name取数据，结果拿到undefined。解决办法是统一规范，我习惯后端返回的字段一律用驼峰命名，前端也用驼峰取数。

问题二：POST请求报403。排除跨域配置的问题之后，大概率是CSRF防护导致的。Spring Security默认开启CSRF防护，如果没配置关闭或没在请求里带上CSRF Token，POST/PUT/DELETE请求会被拦截。毕设项目直接关闭CSRF防护即可。

问题三：响应正常但页面不刷新。通常是Vue的响应式数据更新问题。在Vue 3里，用reactive定义的数组，通过索引直接修改数组元素不会触发视图更新，要用数组.splice(index, 1, newValue)或者直接用ref定义数组。

问题四：数据库连接报时区错误。JDBC连接串里要加上serverTimezone=Asia/Shanghai，不然MySQL 8.x会报“The server time zone value”的错误。这个问题在IDEA里新建数据库连接时就会遇到，连接串配置好就能避免。

问题五：端口被占用。SpringBoot默认8080、Vue默认5173或8080，两个项目可能冲突。我在开发时习惯把SpringBoot的端口改为8081，在application.yml里配置server.port: 8081，前端Vite的开发服务器端口保持默认，跨域问题通过Vite的代理配置解决，而不是在前端代码里写死后端地址。

6.3 演示环境的部署：本地跑起来的一套标准动作

答辩现场不保证有网络，所以最好的演示方式是本地部署，所有服务都在自己的电脑上跑起来。你需要准备三样东西：MySQL服务在运行、SpringBoot后端已启动、Vue前端已启动。

MySQL服务确保本机能连上，这里要注意数据库连接串里用户名密码和代码里配置的一致。SpringBoot项目启动前先确认application.yml里数据库连接信息有没有写对。Vue项目启动前先npm install安装依赖，再npm run dev或者npm run build之后用nginx托管。

如果你不想在答辩现场手忙脚乱，提前把启动顺序写成一个说明文档：第一步启动MySQL，第二步启动后端，第三步启动前端。项目文档里要包含完整的启动教程，这个放在第7章详细说。

关于打包，后端可以用mvn clean package -DskipTests打包成jar包，然后java -jar 包名.jar直接运行。前端Nginx部署有两种方式：一是npm run build生成dist目录，把dist目录部署到nginx；二是开发模式下直接npm run dev，交给答辩现场用浏览器访问开发服务器地址。我更推荐用nginx托管dist目录，因为这样可以模拟真实的部署环境，也更容易演示给评委看。

7. 项目文档的撰写思路：文档不是凑字数的，是给评委看的

7.1 文档结构：标准模板与本项目的差异化侧重点

这个项目的交付物包括源码、数据库、文档三大件。文档的质量在答辩时占的比重非常高，但也是很多人最不重视的部分。有些同学从网上随便找个模板改个标题就交了，内容和自己做的项目完全对不上，评委一眼就能识破。

标准的结构性文档一般包含这些章节，但每个项目要突出的重点不一样：

差异化在哪里？普通的管理系统模板强调的是增删改查，而情绪宣泄平台的核心卖点是“情绪记录与可视化分析”和“匿名倾诉与社区互动”。文档里要花更多篇幅说明这两个模块的业务逻辑和实现方案，而不是把重点放在普通的登录注册和用户管理上。

7.2 接口文档怎么写得让评委看得懂

写完后端接口后，接口文档是必交的内容。有两种产出方式：一种是用Swagger / Knife4j自动生成，另一种是手写Markdown文档。对于毕设项目，我建议两种结合：代码里加Swagger注解，生成在线文档；导出一份接口说明放进项目文档里。

接口文档至少要包含：接口名称、请求方式、请求路径、请求参数说明、返回参数说明、示例。不需要写得多花哨，但必须准确、完整。一个简单的接口描述示例：

### 新增情绪记录 - 请求方式：POST - 请求路径：/api/emotion/record - 请求参数： | 参数名 | 类型 | 必填 | 说明 | |--------|------|------|------| | emotionType | string | 是 | 情绪类型代码，如happy、sad | | content | string | 否 | 情绪描述内容 | | emotionScore | integer | 是 | 情绪评分，1-5分 | - 返回示例： { "code": 200, "message": "操作成功", "data": { "id": 18, "emotionType": "happy", "content": "今天项目上线成功，很有成就感！", "emotionScore": 5, "recordDate": "2025-01-15 18:30:00" } }

接口文档的价值在于：评委不用去翻代码，只看文档就能判断你的接口设计是否合理、功能是否完整。如果你的文档里能清楚列出每个模块的接口列表，说明你对自己的系统了如指掌，答辩时问到你也能对答如流。

7.3 一份好文档的隐藏加分项：部署手册和操作说明

项目文档除了开发文档，还应该包含一份部署手册和一份操作说明。这两个不一定作为正文章节，但作为附录放进去非常加分。

部署手册的内容是：环境要求（JDK、MySQL、Node版本）、数据库初始化步骤、后端启动步骤、前端启动步骤、浏览器访问地址。写的时候要用第一人称实操的视角，把自己部署的过程一步步记录下来。

操作说明适合给评委演示时用：系统有哪些功能、每个功能怎么操作、入口在哪里。比如“用admin账号登录后台，点击左侧菜单的用户管理，可以看到所有注册用户列表，支持启用和禁用操作”。这份文档相当于给评委的演示脚本，你照着演示，评委也能对照着看，思路清晰，体验很好。

8. 项目复盘：从“能跑”到“像样”的三个关键习惯

最后分享一下我在做这类全栈项目时的几个习惯，不算什么高级技术，但确实是在反复踩坑中沉淀下来的。

第一，写代码前先画接口列表。哪怕你不用Swagger，也先把每个模块需要哪些接口、每个接口的入参出参是什么列在一张表里。这样做至少有两点好处：建数据库表的时候知道字段该怎么设计，写前端页面的时候知道数据从哪来。

第二，前后端分离项目一定要保持数据契约一致。后端返回的数字用整数就统一用整数，布尔值就统一用布尔，不要某个接口返回一个字符串"1"，另一个接口返回数字1。前端多个页面使用时很容易在这些细节上出错，排查起来非常浪费时间。

第三，所有配置变量化。数据库连接、端口号、文件上传路径、跨域允许的域名，都放到application.yml里统一管理，不要散落在代码里。我见过有人在Controller里硬编码了一个本地路径，结果换一台电脑运行，文件上传功能就报错。配置变量化之后，换环境只需要改配置文件，代码不用动。

“基于SpringBoot + Vue情绪宣泄平台”这个项目，技术路线是清晰的，架构也很经典，但要把它做成一个真正“像样”的毕设或者学习项目，考验的不是某个单点技术，而是从数据库设计到前后端联调再到文档输出的完整工程能力。把上面这8个章节的每个环节都落实到位，你交付的不只是一份源码加数据库脚本，而是一个逻辑自洽、演示流畅、文档完善的项目作品。