企业官网建设流程全解析

1. 项目整体解读与设计思路

“SpringBoot+Vue+MySQL 学生心理压力咨询评判平台”这个名字，看起来就是一个典型的毕业设计级全栈Web项目。但真正接手的人会发现，它其实不是一个单纯的“增删改查”系统——它把前端展示、后端业务逻辑、数据库设计、算法支撑、论文撰写和部署交付串成了一个完整闭环。这篇文章我按自己做毕业设计带项目的习惯，把这个平台从架构到部署、从代码到论文，完整拆开讲一遍。

声明：文中所有涉及实例如“某高校”“某同学”“某导师”，均为虚构代称，仅用于说明常见场景，不指向任何真实院校或个人。

1.1 这个项目到底在解决什么问题

高校学生心理压力问题这些年一直是学生工作的高频话题。传统的做法是问卷普查、约谈排查，但数据分散在Excel、纸质问卷甚至辅导员的手记里，很难形成持续跟踪。这个平台的核心价值，是把手动、零散的心理压力调查过程，转变成一个在线化、数据化、可视化的完整闭环。

简单理解，它的业务流程是：学生登录前台，填写一套或多套量表；后台自动计算得分，并根据预设的等级阈值给出压力等级或倾向描述；心理咨询中心的老师登录管理端，查看统计报表、导出数据、标记重点关注对象；系统管理员维护量表题库、用户权限、年级专业等基础数据。

所以这个项目并不是单纯“做个网页”，而是一个“线上测评 + 自动评判 + 可视化分析”的轻量级业务系统。它的技术栈非常主流——SpringBoot做后端，Vue做前端，MySQL做存储。这个组合在当前就业市场和毕设答辩中都很讨喜：既有后端接口设计，又有前端交互，还有数据库建模，三块能力点全占齐，评委问什么都不虚。

1.2 为什么选择这套技术栈

选型这里我必须多说几句。很多同学一上来就想整微服务、Redis、RabbitMQ，觉得技术越新越显档次。但毕业设计的核心评判标准从来不是技术多，而是“逻辑通、可运行、能讲清”。

SpringBoot的优势在于：约定大于配置，不用写一堆XML配置文件；内嵌Tomcat，打包就是一个Jar，部署简单；整合MyBatis-Plus后，单表CRUD几乎不用手写SQL；社区庞大，遇到问题搜一下就有答案。Vue则解决了前端组件化、数据绑定、路由管理的问题，用Vue2还是Vue3看学校要求，但整体开发体验比纯HTML+JQuery高出一个量级。MySQL作为关系型数据库，对这个项目体量完全够用，配合Navicat或DataGrip做可视化操作非常顺手。

至于为什么不用更复杂的技术，我的经验是：复杂方案意味着更多不可控因素。比如Redis用来存验证码没问题，但如果答辨时讲不清楚淘汰策略和持久化机制，反而给评委留问询口。所以这个项目的技术选型，本质上是一种“稳健且完整”的策略——每一层技术都是主流、能说清、能展示，这就够了。

经验之谈：答辩时评委不关心你用没用云原生，他们更关心“为什么选这套方案”“数据怎么流转”“遇到某个问题怎么排查”。

2. 系统功能模块与角色权限拆解

这部分是设计阶段的重头戏。千万不要上来就写代码，先把功能模块图在纸上画明白。一个毕业设计系统，一般分前台和后台两块，但“学生心理压力咨询评判平台”比一般系统多了一层业务逻辑——量表评判。

2.1 三端角色的权限边界

系统建议设计三种角色：学生、咨询老师、系统管理员。这里的关键不是“三个角色登录页面”，而是不同角色能做什么、不能做什么。

学生端（前台）：注册登录、修改密码、查看个人信息、参与心理测评（填写量表）、查看自己的测评结果和历次记录、查看心理咨询预约或留言回复（如果有预约模块）。

咨询老师端（后台）：查看学生测评数据总览（按学院、专业、班级维度统计）、查看单个学生的历次测评轨迹、查看压力等级分布可视化图表、对重点关注学生进行标记和备注（仅老师可见）、导出测评汇总数据（Excel）。

系统管理员端：管理学生与老师账号（增删改查、重置密码）、管理学院专业班级基础数据、管理量表题库（题型、选项分值、所属量表）、配置评判等级阈值、操作日志查看。

这三个角色是典型的RBAC（基于角色的访问控制）模型。前端用路由守卫控制页面入口，后端用拦截器或AOP校验接口权限，双端校验是必须的——前端隐藏菜单只是体验问题，后端不校验就是安全漏洞。我在实际项目中遇到过某同学只在前端做了权限判断，结果直接访问后端API就能绕过管理，这是大忌。

2.2 核心业务表设计思路

数据库是这个项目早期最容易返工的地方。表设计不好，后面写代码和论文都会被拖累。我建议最低限度做这些表：

用户相关：user（主表，含账号/密码/角色/状态）、student_info（学号/姓名/学院/年级/班级等）、teacher_info（工号/姓名/所属部门等）。

心理健康域：scale（量表定义表，如量表名称、描述、量表类型）、question（题目表，关联量表编号、题干、选项类型）、option（选项表，关联题目编号、选项文本、选项分值）、assessment_record（测评记录主表，关联学生、量表、总得分、等级、提交时间）、assessment_detail（测评明细表，关联记录主表，存每道题的答案和分值）。

业务辅助：appointment（预约表，学生与咨询老师的预约记录）、attention_student（重点关注表，老师标记的学生清单）、operation_log（操作日志表）。

这里我特别说一个“用户画像分区”的技巧：不要把学生个人信息和测评数据全塞在user表里。user只做认证登录，student_info做档案，assessment_record做行为数据。这样拆有三个好处：一是表结构分层清晰，论文里画ER图好看；二是权限控制更好写，敏感数据可按角色隔离；三是后期如果要加字段，不需要动user主表，迁移成本低。

3. 数据库设计落地与关键字段规划

数据库这一步，很多人喜欢直接导入现成的sql文件，但答辩最怕的就是“这个字段什么意思？”答不上来。老老实实把字段设计思想搞明白，才是省力又稳妥的做法。

3.1 数据库三步走流程

我的习惯是三步走：概念模型 → 物理模型 → 初始化脚本。概念模型就是ER图，让导师和论文都看得懂；物理模型落到表结构和索引；初始化脚本则是直接生成可导入的建库语句和测试数据。

建库这一步，字符集选utf8mb4而不是utf8。utf8mb4兼容更全，四字节表情符号也能存，虽然不是刚需，但可以避免后续导入数据时出现“无效字符”的尴尬问题。

核心的user表，密码字段建议存MD5加盐后的值，而不是明文。这一步是答辩高概率问点，必须答得出来。通常做法是注册时取一个随机盐值（例如UUID截取8位），密码 = MD5(盐 + 明文密码)，数据库同时存盐值和加密结果。校验时按同样算法重新计算比对即可。

assessment_record表两个最关键的字段是total_score和level。total_score是量表各题目得分的总和，level是系统根据总分和阈值自动判定的压力等级。这两个字段看着简单，但在统计和可视化图表里是核心数据源。建议在level字段上建索引，因为后台首页的统计报表基本都会按level做分组查询。

3.2 测评记录的索引设计与数据冗余

测评明细表（assessment_detail）会随着使用次数膨胀，如果学校有几千学生每人测了多次，明细表很快就上万行了。所以必须给外键字段和常用查询字段建索引。

我的实践方案是：

• assessment_detail表建联合索引（record_id, question_id），避免一次查询走全表扫描。
• assessment_record表按student_id、scale_id、create_time三个字段分别建普通索引，方便按学生查历史、按量表查记录、按时间范围做统计。
• 如果后期数据量继续膨胀，可以按student_id做分表或按月归档，但毕业设计阶段索引就足够了。

另外有个容易被忽视的点：冗余设计。比如record表里已经有total_score和level了，为什么detail表还要存每一题的option_score？因为如果要反向核查某个学生的压力来源是哪几道题，detail表的细粒度数据就是证据。保留细粒度数据，统计分析才有依据，这是数据仓库设计里的“事实表+明细表”思想，哪怕在毕设谈出来，也是一个加分项。

3.3 造测试数据比想象中重要

很多同学到了联调阶段才发现，自己辛辛苦苦写好的图表组件，数据列表却是空的，显示效果完全无法展示。我建议在初始化脚本里一次性造好三类数据：管理员账号、若干个辅导员或咨询师账号、至少100个学生账号，其中压力等级分布刻意做成“大部分正常、少部分轻度、个别中重度”的比例，这样前端图表的柱状分布和饼图效果才会真实有说服力。

造数的时候可以使用存储过程或直接在sql脚本里写循环插入。注意身份证号、学号等字段要有规律但不重复，密码统一初始化为一个默认值，如“123456”，注册后提示修改密码——这是毕设演示的标准操作。

4. SpringBoot后端核心实现

后端这层是整个系统的“大脑”，既要稳，又要能让答辩老师一眼看懂结构。我强烈建议后端采用标准三层架构：Controller层（接收请求）、Service层（业务逻辑）、Mapper层（数据访问）。这是最稳妥的模式，千万不要在Controller里堆业务代码，不然答辩抽问时容易露怯。

4.1 项目初始化与Maven依赖选型

创建SpringBoot项目建议直接使用Spring Initializr（IDEA自带的创建向导），也可以手动在pom.xml里配置依赖。本项目的核心依赖就这几组：

• spring-boot-starter-web：Web MVC基础。
• mybatis-plus-boot-starter：MyBatis-Plus，单表CRUD神器。
• mysql-connector-java：MySQL驱动，版本要和MySQL适配。
• lombok：简化实体类（直接用@Data注解）。
• hutool：工具类库（生成验证码、日期处理都很方便）。
• spring-boot-starter-validation：参数校验（@Validated）。

说到版本适配，这是第一个容易踩的坑。SpringBoot 2.x配MyBatis-Plus 3.x很顺畅，但SpringBoot 3.x对应的是JDK 17，MyBatis-Plus也建议用3.5.x以上。如果学校电脑环境是JDK 8，就老老实实用SpringBoot 2.7.x。我见过一个同学直接开SpringBoot 3，结果本机JDK版本不够，启动时报错，折腾半天才搞明白。毕业设计抠时间要紧，别拿盲目的“求新”给自己挖坑。

配置方面，注意application.yml里MySQL连接的时区问题：

spring: datasource: url: jdbc:mysql://localhost:3306/your_database?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

这段配置里，serverTimezone不写，数据库操作时会报时区错误；logic-delete是MyBatis-Plus的逻辑删除配置，一旦开启，删除操作自动变成update语句。

4.2 实体类与统一响应体设计

实体类（Entity）每个表对应一个。最方便的方式是让实体类字段和数据库表字段保持一致，用@TableName注解指定表名，主键上加@TableId(type = IdType.AUTO)。我在实际带某同学做模拟项目的时候，有个特别深刻的教训：字段名一旦用thisIsCamel这种驼峰命名，数据库里是下划线命名的，就一定要在全局配置里开启map-underscore-to-camel-case: true，否则查询结果全是null。

统一响应体这个设计，可能初看觉得繁琐，但非常值得做。定义一个通用的Result类：

@Data public class Result<T> { private Integer code; 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(500); result.setMessage(message); return result; } }

所有Controller方法都返回Result类型，这样前端的axios拦截器就可以统一处理状态码，不需要每个页面单独判断。查询成功、新增成功、删除成功，只改message文本即可，代码量反而少了。论文里的类图也会因为这个统一响应体更有设计感。

4.3 测评流程背后的完整时序与打分逻辑

测评流程是整个系统最容易在答辩中被深挖的核心业务，涉及数据一致性、并发安全、表关系维护等多个要点。深入拆开，它的完整时序是这样的：

• 学生提交测评请求，传输数据为［量表ID，学生ID，答题明细列表］。
• 后端先做参数校验：量表是否存在、学生是否已登录、是否重复提交（同一量表当天是否已提交）。
• 从量表、题目、选项关联数据中取出全部题目的标准选项，进行逐题校验。此时如果前端被绕过而直接裸调接口，传入了不属于本题的选项ID，后端能通过关联查询判断并返回参数错误。
• 核心打分逻辑：遍历答题明细，把每个选项的分值累加，得到总得分；再通过等级阈值映射，自动判定压力等级。
• 落库策略：使用事务（@Transactional）。先插入assessment_record主记录，拿到自增主键，再批量插入assessment_detail明细；如果明细插入中出现任一条失败，事务回滚，整单作废。
• 事务提交后返回前端结构化响应：总得分、等级、对应的建议提示文本。前端的评估报告页面基于这个响应渲染分数、等级、提示语三块卡片。

等级判断我推荐在Service层实现，而不是在SQL里算——方便日志打印、方便规则调整，也方便在论文时序图里画出清晰逻辑。参考访法示意如下：

public AssessmentResult evaluate(List<AnswerDTO> answers, Long scaleId) { // 1. 判空与合法性校验 if (answers == null || answers.isEmpty()) { throw new ServiceException("提交数据为空"); } // 2. 载入量表与标准题目 // 3. 逐题匹配评分 int totalScore = 0; for (AnswerDTO answer : answers) { Option option = optionMapper.selectById(answer.getOptionId()); if (option == null || !option.getQuestionId().equals(answer.getQuestionId())) { throw new ServiceException("选项与题目不匹配"); } totalScore += option.getScore(); } // 4. 规则引擎：等级判定 LevelRule rule = ruleMapper.findByScaleAndScore(scaleId, totalScore); // 5. 封装返回对象 }

4.4 拦截器与JWT登录态管理

登录态管理是常规又重要的一环。可以用JWT（JSON Web Token）做无状态登录，也可以用Session。我是建议用JWT，因为前端Vue拿到token存到localStorage里，每次请求在axios拦截器上带Bearer Token，前后端分离起来非常顺。后端的核心逻辑：

• 登录成功时，根据用户信息（userId、role）生成一个有效期2小时的Token。
• 写一个LoginInterceptor，在HandlerInterceptor的preHandle方法里解析Token，解析失败或过期的统一返回401。
• 注册拦截器时，放行登录、注册接口，其余路径全部校验。管理端的接口再加一个角色校验（如@RequireRole("ADMIN")注解），由自定义AOP切面检查ThreadLocal里的用户角色。

JWT涉及一个坑——HmacSHA256签名的密钥不要写在业务代码里，放到application.yml中用@Value注入，答辩时可以讲“密钥外置，防止泄露”。

4.5 文件导出与操作日志

导出Excel是管理端的常见功能。用EasyExcel（阿里开源工具包）写起来很快，核心三步：定义导出Excel对应的数据模型类，加上@ExcelProperty注解；查询数据转成List；调用EasyExcel.write()生成文件流响应给前端。

这里有一个需要注意的编码问题——文件名中有中文时，需要先转URL编码，否则前端下载文件时文件名会乱码。

操作日志的话，可以做一个简单的AOP切面：自定义一个@OperationLog注解，标在需要记录日志的方法上，切面里记录用户ID、请求路径、方法描述、IP、耗时、操作时间。答辩谈到“安全性”“可追溯性”时，这就是一个活生生的亮点，比嘴上说说有说服力。

5. Vue前端核心设计与页面实现

Vue前端这层，决定了用户能直接触碰到的系统体验。如果构建风格很粗糙，答辩现场观感会下降很多，甚至掩盖后台写得再好的优势。所以这一步值得好好打磨。

5.1 前端项目结构与路由设计

前端建议基于Vue CLI或Vite创建。Vite构建速度快，对Vue3支持更好；但如果学校要求Vue2，还是CLI最稳。项目内部结构，我一般这么分：

src/ api/ // 接口请求封装，按模块拆文件 assets/ // 静态资源 components/ // 公共组件 router/ // 路由配置文件 stores/ // Pinia或Vuex状态管理 views/ front/ // 前台页面 admin/ // 管理后台页面 utils/ // 工具类（axios实例、格式化方法）

路由设计上，给每个一级页面配一个meta字段，存requiredRoles。路由守卫里校验用户角色，没有权限直接重定向到首页。这样管理后台的菜单和页面，学生账号永远访问不到，前端体验和安全观感都到位。

5.2 axios实例封装与Token注入

前端请求层是最容易写乱的地方。我推荐封装一个独立的axios实例，统一做三件事：

• 请求拦截器：从localStorage读取token，加到请求头（Authorization: Bearer xxx）。
• 响应拦截器：返回的code为200时直接返回data；code为401时跳转到登录页并清理本地登录信息；其他code用Element Plus或Ant Design Vue的Message做全局提示。
• 统一错误兜底：网络异常、后端5xx等，弹出统一错误提示，避免每个页面重复写catch。

import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code === 401) { localStorage.removeItem('token') window.location.href = '/login' return Promise.reject(new Error('登录已过期')) } return res }, error => { console.error('请求出错', error) return Promise.reject(error) } ) export default service

5.3 测评报告展示与可视化模块

测评报告页必须做得有“温度”。不要只甩一个分数，可以做成三块：顶部大字体的等级标签（正常/轻度/重度，配上不同配色，比如绿色、橙色、红色）；中部展示本次总得分、测评时间、量表名称、以及建议提示语；下部做“历史趋势图”，用ECharts折线图展示历次分数变化。

ECharts的使用不复杂。npm安装echarts，在组件里import，init之后setOption即可。但有一点经验，图表需要一个稳定的容器高度，否则可能出现图被压扁或消失的问题。

统计管理端的话，建议至少放四个可视化组件：

• 压力等级分布饼图（正常/轻度/中度/重度占比）；
• 各学院测评参与率条形图；
• 近半年测评量趋势折线图；
• 筛选条件下载学生明细表。

如果整个系统前端页面有20个以上，工作量很大，某同学当初的解决方案是把常见表格封装成通用组件，只传配置项（columns + data + pagination），再配合一个searchForm插槽，开发速度立刻起来。这个技巧在自己做前端的效率提升上非常明显。

5.4 Element Plus表单校验与交互细节

管理后台的表单建议用现成UI库，Element Plus（Vue3）或Element UI（Vue2）都行。这里有三个容易被轻视的细节：

其一，表单校验必须要做。比如新增用户时，学号必填、手机格式校验、邮箱格式校验。Element的Form自带rules机制，配置一下就能解决，不做的话前端体验很粗糙。其二，表格操作栏的“删除按钮”一定要二次确认，Element的ElMessageBox.confirm写完有确认框，防止误操作。其三，分页参数要稳定。我见过很多同学改页码、改每页条数后，查询条件丢失或列表重置，排查半天发现是list表单没绑定。

6. 心理量表评判逻辑与数据安全

写到这里，终于到业务特色的核心了。很多同学不知道“评判”两个字背后有多少细节，甚至最初的想法是写死一套规则。但这样做，后期拓展量表和调整阈值时会异常痛苦。更好的设计，是做一个可配置的规则引擎逻辑。

6.1 量表结构与计分规则的配置化

量表可以分两类：一类是自评量表，每个题目的选项固定，按选项分值累加，例如（非常不符合=1分、不符合=2分、符合=3分、非常符合=4分）；另一类是类似SCL-90（症状自评量表）这种按因子划分的量表，不仅可以算总分，还可以按因子维度算因子分。

我建议题库表结构里加一个字段factor（所属因子），这样既可以统计总分，也可以按因子校验。例如某量表有“焦虑倾向”“抑郁倾向”“社交敏感”三类因子，每道题属于一个因子，那么测评结果中就可以额外展示“你在焦虑倾向维度的得分为X分，超过常规参考范围”这类更细的解读。这个设计在答辩展示中非常亮眼，因为它说明你不仅会写代码，还懂业务结构。

阈值配置做成一张规则表，例如：0-15分=压力正常，16-25分=轻度压力，26-35分=中度压力，36分及以上=重度压力。管理员可以随时调整规则。开发时我在规则表里设计了score_min、score_max、level、suggestion四个字段，suggestion字段存等级对应的建议文案。前端在结果展示时直接取建议文案输出即可。

6.2 敏感数据脱敏与隐私注意事项

心理测评平台涉及非常敏感的个人数据。答辩时关于“数据安全性”几乎是必问项，这里建议至少做到以下几点：密码绝对不存明文，必须加盐加密；数据库连接串不暴露在浏览器请求里——不要在前端页面出现后端数据库地址；测评记录与身份信息分表存放，列表中展示姓名，详情中展示成绩，查询接口后端按当前用户的角色做数据范围过滤。

另外，规定测评结果为“仅本人和咨询老师可见”。前端路由上学生只能访问自己的记录，管理端则按权限看到汇总或明细。把“隐私保护策略”作为单独一节写进论文，除了内容丰富度，还能体现设计者的人文关怀意识，这在评分角度上是很加分的。

6.3 数据报告导出与统计分析

统计报表建议用MySQL的聚合查询。基本的几条要能脱口而出：

-- 各等级人数统计 SELECT level, COUNT(*) AS cnt FROM assessment_record WHERE scale_id = ? GROUP BY level; -- 各学院平均分对比 SELECT s.college, AVG(r.total_score) AS avg_score FROM assessment_record r JOIN student_info s ON r.student_id = s.id GROUP BY s.college; -- 近30天测评提交趋势 SELECT DATE(create_time) AS day, COUNT(*) AS cnt FROM assessment_record WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE(create_time);

三条SQL正好匹配前端三个图表。管好查询效率，后面写论文的“性能分析”章节也有素材。导出Excel的时候，建议按当前筛选条件导出，而不是导出全量。全量数据导出在演示环境只有几百条无所谓，但真实场景下会造成不必要的压力，设计时要带上筛选参数。

6.4 并发提交与重复测评保护

有个隐藏的并发问题：如果学生快速连点两次“提交测评”，后端很可能插入两条一模一样的测评记录。解决方式我试过两种：一种是把提交按钮置灰（前端体验优化，但不防恶意请求）；另一种是后端做幂等逻辑——校验同一学生、同一量表、同一时间窗口内是否已存在记录，若存在则拒绝。第二种才是真正的保护。

答辩如果只答“做了按钮防重复提交”，其实不够稳；如果答“后端仍做了校验，因为前端拦截是可以被绕过的”，这个回答的深度就完全不一样了。

7. 论文结构、答辩准备与部署避坑

论文和部署往往是最后才想起、但实际最影响分数和交付质量的部分。我把它俩放在一起讲，因为它们的共同点是：不靠智商，靠提前准备。

7.1 论文写作的思路与章节安排

某同学第一次写毕设论文时，把1万字堆在一起，导师看了直摇头。后来我建议他按“技术实现+业务实现”双线写，结构就变成：

• 第一章，绪论：研究背景、现状与发展趋势、研究内容和意义。
• 第二章，相关技术介绍：SpringBoot、Vue、MySQL、ECharts，每项写“简介+特性+为什么本项目使用它”。
• 第三章，需求分析：用户角色分析、功能需求、非功能需求（安全性、易用性、系统性能要求）。
• 第四章，系统设计：总体架构图、功能模块图、数据库ER图与核心表结构说明、接口设计。
• 第五章，系统实现：按前端/后端划分，突出关键模块核心代码片段和运行截图（测评结果页、统计图表、权限拦截器）。
• 第六章，系统测试：设计测试用例表格（正常流程、异常流程、权限控制），展示结果截图。
• 第七章，总结与展望：当前系统的不足（如未引入Redis缓存、未做移动端适配）、改进方向（如AI辅助评估、消息提醒）。

这套结构里，“相关技术”和“数据库设计”是最容易凑字数的部分，但真正提分的是第五章和第六章。运行截图存个十几张，答辩PPT就能直接用。

7.2 部署流程与常见环境问题

这个项目部署其实不算难，发布形态不必追求Docker化，但可行的标准方案是这样的：

1. 前端构建：npm run build，生成dist目录。
2. 后端打包：Maven执行package，打成Jar包。
3. 服务器环境：安装JDK（版本和本地一致）、MySQL（或者直接购买云数据库）、Nginx（服务器根目录指向dist，并配置/api反向代理到Jar包所在的端口）。
4. 导入数据库：使用mysql命令行或导入工具，导入初始化脚本。
5. 启动服务：nohup java -jar your-project.jar > logs/run.log 2>&1 &，日志输出到文件，方便排查。
6. 访问验证：浏览器打开服务器公网IP或域名，确认前端页面和接口都能正常响应。

常见的“为什么本地能跑，服务器跑不起来”问题排查顺序比较固定：先看端口有没有被占用（linux：netstat -tlnp | grep 8080）；再看日志里有没有数据库连接失败（多为时区或密码问题）；再检查前端请求有没有走到后端（用F12看网络请求是否404）。

提示：云服务器安全组要将放行的端口开着，很多同学项目对了，死活访问不了，最后发现只是没给安全组加规则。这个我踩过太多次，严重建议优先检查。

7.3 答辩现场演示的注意事项

答辩无非两部分：讲PPT、演示系统。演示系统最怕“现场翻车”，所以建议准备一条“黄金演示路径”——注册账号登录 → 完善信息 → 做一次测评 → 查看结果页 → 切换老师账号看统计图表 → 切换管理员账号管理用户。这条路径越短越稳，每步停留控制在10秒内。

事先必须做的两个动作：一是清理测试数据，把干扰记录删除，演示时保持数据干净；二是网络依赖处理——如果答辩教室没网，建议确认本地环境能不能跑，或者准备离线版的演示视频兜底。我见过一个同学演示前10分钟才发现教室WiFi连不上，结果云服务器上的案例访问不了，只能干讲PPT，那叫一个狼狈。

7.4 给新手的十点避坑心得与经验总结

结合自己实际做过的项目带项经验，把高频的坑集中整理出来，送给准备开工的各位：

• 序号一：永远先搭数据库，再写代码。脑子里的需求映射到表上，写代码才知道每行数据从哪来、到哪去。
• 序号二：密码、身份证号等敏感信息在日志中避免打印。日志打印全量参数的习惯要早点改掉，不然线上日志永远是信息泄露源。
• 序号三：前后端联调时先把后端的Postman自测做完，再开始前端对接。前端能甩锅给后端的责任全部先消灭自己的问题。
• 序号四：页面加载时默认展示第一页数据，不要等用户点了搜索才有内容，这种细节比功能多还显效果。
• 序号五：Mapper层的SQL尽量用MyBatis-Plus的条件构造器，简单查询不要手写XML。手写XML多了，稍不留神写错拼写就是一大段的排错时间。
• 序号六：ECharts画完图后，记得加window.onresize = () => chart.resize()，不然拖动浏览器窗口图表会变形。
• 序号七：项目启动时打印自定义Banner，把项目名称和端口号显示出来。对排查多项目同时跑时的端口冲突很有帮助。
• 序号八：所有新增、修改操作注意操作日志的记录，尤其是管理员操作。答辩提到“配合审计要求”时，这就是证据。
• 序号九：写论文的时候随手截图，不要等开发完再补。回填截图比现场重跑一遍省太多事。
• 序号十：尽早做一次完整的端到端测试。每一步按“输入-处理-输出”测试，不然最后两天连续失眠的是你自己。

8. 一点个人心得

这类平台项目，技术上没什么“天顶星科技”，但胜在业务链条完整、技术选型主流，很适合拿来吃透全栈开发的核心流程。我强烈建议别把源码一导入、跑起来就完事，把数据库表结构自己整理一遍，把接口文档自己写一遍，再把测评打分流程对着代码理一遍，答辩时的底气和熟练度完全不一样。

最后留一个问题给准备做的同学思考：如果让你设计一个“匿名倾诉留言板”功能，学生可以匿名留言，咨询师在后台回复。你的数据库表结构要怎么设计，才能做到“学生匿名、咨询师可见、系统能关联到人但不暴露给其他学生”？想清楚这个，你对这个项目的理解就又上了一个台阶。