企业官网建设流程全解析

先说个细节，标题里写的是“心里健康”，严格说应该是“心理健康”。不影响搜代码，但如果你拿着这四个字去写论文或者答辩PPT，很容易被导师挑刺。下面我讲的系统涉及的是心理健康评测方向，算是典型的SpringBoot课程设计或毕业设计项目，用的技术栈不算新，但胜在完整：前端有页面、后端有服务、数据库有表结构、部署有文档、代码有讲解。如果你正准备拿这类课题练手，或者需要一套能跑通全流程的项目做参考，这篇内容应该能帮你少走不少弯路。

整个系统解决的问题很直接：把传统的纸质心理量表搬到线上，让青少年可以在线完成评测，系统根据答题结果自动计算得分、生成评测报告，老师或家长可以在后台查看结果、跟踪状态。业务上不复杂，但麻雀虽小五脏俱全，登录鉴权、角色权限、量表管理、答题记录、报告生成、历史档案这些模块一个不少。适合的人群也清晰：正在做Java方向课程设计的在校生、需要一套完整项目用于毕设答辩的同学，以及想系统过一遍SpringBoot前后端分离项目怎么从开发到上线的初学者。

1. 项目整体设计与技术选型

1.1 从业务倒推：为什么选择SpringBoot单体架构

做课程设计和毕设，最容易犯的毛病是一上来就搞微服务、搞分布式，项目还没跑起来先把复杂度拉满。青少年心理健康评测系统这种业务场景，用户量不会大到需要横向扩展，评测流程又是强事务性的，一套完整的单体应用完全够用，而且对于学习和答辩来说，单体架构的代码更好讲清楚。

SpringBoot在这个场景里是最合适的载体，原因有三。第一，自动配置大大降低了搭建成本，一个spring-boot-starter-web就能把一个可运行的Web工程拉起来，这对时间紧迫的课设项目非常关键。第二，生态成熟，做评测系统必需的能力——数据库访问、权限控制、Excel导入导出、定时任务，SpringBoot都有现成的starter可以整合。第三，部署简单，java -jar一条命令就能跑，相比传统SSH工程需要配置外部Tomcat，省掉了整整一个坑位。

前端选择了Vue加上Element UI这套组合，属于目前前后端分离项目的常用搭配，能覆盖评测页面、管理后台的绝大多数界面需求。如果配合现成的后台管理模板，样式部分基本不用从零写，可以把精力集中在业务逻辑上。

1.2 技术栈拆解与核心依赖清单

这个项目用到的技术栈放在2024年依然是主流，没有太老也没有太激进，兼容性和学习成本都比较平衡。

核心依赖里，MyBatis-Plus是提升开发效率的关键。传统MyBatis写一个分页查询要手写PageHelper或者自己拼LIMIT，而MyBatis-Plus直接提供Page对象加selectPage方法，几行代码搞定。对课程设计来说，代码量少了，出Bug的概率也低了，答辩时也更容易说清楚。

1.3 数据库设计与量表模型设计

数据库是整个系统里最不该偷懒的部分。评测系统核心表有这几张：用户表（学生、老师、管理员）、量表表（定义一份评测问卷）、题目表（量表下的具体题目）、选项表（每题的可选答案）、答题记录表（某个用户某一次评测的所有答案）、评测报告表（计算后的分数和结论）。

量表模型是这个系统里值得重点讲的部分，因为它的设计直接影响代码的复杂度。一种常见做法是给题目加一个dimension字段，代表这道题属于哪个维度。比如焦虑自评量表（SAS）有20道题，每道题背后的维度是焦虑，但更复杂的量表可能区分多个维度，比如抑郁量表会包含“情绪低落”“兴趣减退”“身体症状”等维度，这时题目结构就需要多一层分组：

题目表 tb_question - id - scale_id // 所属量表 - question_no // 题号，如Q1、Q2 - content // 题干内容 - dimension // 所属维度，如depression、anxiety - sort_order // 排序字段

选项表的设计也要注意。量表的评分方式通常有两种：正向计分和反向计分。比如“我觉得生活很有意义”这种正向题，选“没有”得4分；而“我感到绝望”这种反向题，选“没有”反而得1分。所以选项表里除了选项文字，一定要有一个score字段，这样计算时直接拿选项分值，不用在代码里做复杂的判断题。

实操中我建议在数据库设计阶段就把反向计分的题目标注清楚，可以把is_reverse放在题目表里，这样评分算法统一了逻辑，代码更简洁，后面我会专门讲评分计算的写法。

2. 源码结构讲解与核心模块实现

2.1 工程目录结构与分层习惯

拿到一份SpringBoot项目的源码，第一步不是急着运行，而是先看懂目录结构。这个项目的包结构比较标准，按照controller、service、mapper、entity、config、common、utils分层：

com.example.psychology ├── controller // 接口层，接收前端请求 ├── service // 业务层，核心逻辑都在这 │ └── impl ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库映射实体类 ├── vo // 视图对象，给前端返回的包装类 ├── config // 配置类：跨域、拦截器、Redis等 ├── common // 公共返回结果、异常处理 ├── utils // JWT工具类、日期工具等 └── PsychologyApplication.java // 启动类

这个分层的意义在于职责单一。Controller只做参数接收和结果返回，不写SQL；Service只做业务逻辑，不直接和数据库打交道；Mapper只做数据访问。初学者最容易犯的错是把所有代码堆在Controller里，一个方法几百行，后期根本没法维护。分层虽然多写几个类，但每个类的职责清楚，出问题的时候能快速定位。

实体类方面，我在代码里看到不少同学直接用Lombok的@Data注解，这个建议保留，确实能省掉大量getter/setter的样板代码。但要注意，实体类的字段命名要和数据库下划线格式对应，scale_id对应scaleId，MyBatis-Plus默认开启驼峰映射，只要配置文件里配了map-underscore-to-camel-case: true就不会出问题。

2.2 用户登录与JWT鉴权实现

评测系统的用户分为学生、老师和管理员，登录方式可以统一用账号密码，但鉴权逻辑要区分角色。项目里采用JWT（JSON Web Token）方案，流程是：用户登录成功后，服务端生成一个token返回给前端，前端每次请求在Header里带上Authorization: Bearer <token>，后端通过拦截器校验token是否有效。

JWT工具类核心代码：

public class JwtUtils { private static final String SECRET = "your-secret-key"; private static final long EXPIRE_TIME = 1000 * 60 * 60 * 24; // 24小时 public static String createToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET) .parseClaimsJws(token) .getBody(); } }

这样设计最大的好处是服务端不需要维护session，符合前后端分离的架构特点，在集群部署时也不需要做session共享。但要注意，JWT的密钥不要硬编码在代码里，虽然课设项目这样做问题不大，但如果你以后找工作面试聊到这个点，提到应该是放在配置中心或环境变量里，会显得更专业。

拦截器的实现要注意放行路径，比如登录接口、注册接口、量表列表接口是无需登录也能访问的，其他接口一律校验token。拿拦截器继承HandlerInterceptorAdapter，在preHandle里校验，再把用户信息放入ThreadLocal或请求域中供Service层使用，这也是个常见的加分点。

2.3 量表答题与评分计算逻辑

这是整个评测系统的业务核心。我见过很多实现是前端把每道题的选项序号直接传后端，后端也只存了选项序号，结果算分的时候才发现不知道分值，还要从题目表去反查。正确的做法是：前端答题完成后，把每道题的questionId和optionId一并提交给后端，后端在存储答题记录的同时，根据选项对应的score计算初始得分。

评分计算逻辑的核心步骤：

public EvaluationReport generateReport(EvaluationRequest req) { // 1. 根据量表ID获取所有题目，按维度分组 List<Question> questions = questionMapper.selectByScaleId(req.getScaleId()); Map<String, List<Question>> dimensionGroups = questions.stream() .collect(Collectors.groupingBy(Question::getDimension)); // 2. 遍历每题，从请求中取出选项分值，累加到对应维度 Map<String, Integer> dimensionScores = new HashMap<>(); for (Map.Entry<String, List<Question>> entry : dimensionGroups.entrySet()) { int totalScore = 0; for (Question q : entry.getValue()) { Option selected = optionMapper.selectById(req.getAnswers().get(q.getId())); totalScore += selected.getScore(); } dimensionScores.put(entry.getKey(), totalScore); } // 3. 计算总分，除以题目总数得出标准分（不同量表转换规则不同） int rawScore = dimensionScores.values().stream().mapToInt(Integer::intValue).sum(); double standardScore = convertToStandardScore(rawScore, questions.size()); // 4. 对照等级阈值，生成报告结论 String level = judgeLevel(standardScore); ... }

这里有一个特别容易被忽视的坑：不同量表的总分换算方式不一样。以SDS抑郁自评量表为例，20道题，每题1-4分，原始分范围是20-80分，但报告里通常用的是标准分，标准分的换算公式是标准分 = 原始分 × 1.25，然后根据标准分判定等级：53-62为轻度抑郁，63-72为中度，大于72为重度。如果项目里有多个量表，换算公式一定要提取成策略接口，不要写死在Service里。否则每加一个量表就要改一次评分模块，后期维护会很痛苦。

至于反向计分题，代码实现上有两种方案。一种是在选项表设计时把反向题的选项分值就已经放好，比如正向题的“没有”是4分，反向题的“没有”是1分，这种方案代码最简单，但录入数据时要非常小心。另一种是代码里通过is_reverse字段做转换，代码稍微复杂一点但数据更规范。我个人推荐第一种，因为数据录入的严谨性可以通过人工审核保证，而代码复杂度一旦上去了，调试成本更高。

2.4 评测报告生成与被测者档案管理

评测报告不是简简单单把分数展示出来就完了，清晰的报告设计能大幅提升系统实用性。报告里应该包含五部分：基础信息（姓名、年龄、性别、评测时间）、各维度得分明细、总分与标准分、等级判定结果、参考建议。

参考建议这块值得用心设计。比如焦虑评测结果属于轻度，可以给出“注意劳逸结合，尝试呼吸放松训练，建议定期复测”这类建议；如果是中度或以上，建议文案里应说明“建议及时联系学校心理辅导老师或专业医疗机构”，这里措辞要谨慎，作为系统开发方，不能给出诊断性结论，提供的一般是建议性文字。

档案管理则是把多次评测记录关联到同一个学生ID下，形成时间线视图。学生登录后可以看到自己历次评测的趋势曲线，老师登录后可以看到所带班级的整体情况概览。这部分实现不复杂，用ECharts在前端画折线图即可，后端只需要提供一个查询接口：根据学生ID查询评测记录列表，按时间排序返回。业务逻辑不重，但作为系统的展示亮点，答辩时很有说服力。

3. 部署流程：从本地运行到云服务器发布

3.1 本地开发环境准备与初始化

很多课设项目的部署文档写得太“顺利成章”，默认读者已经装好了全部环境，结果新手第一步就卡住了。这个项目需要的环境清单如下：

环境准备阶段最耗时间的其实是版本匹配问题。比如SpringBoot 2.7版本默认使用Spring 5.3，JDK版本8和11都可以，但如果你的JDK是17，部分旧依赖可能因为模块化限制直接起不来。如果在启动时报java.lang.reflect.InaccessibleObjectException，大概率是JDK版本和Spring版本不匹配，换回JDK 8基本能解决。

数据库初始化方面，项目里一般会附带一个sql/目录，里面是建表语句和初始化数据。建议直接在Navicat或命令行里执行整个SQL脚本，不要手动建表，容易漏字段。执行时注意数据库字符集要设置为utf8mb4，不然中文可能乱码。这一步是新手最容易忽略的，我之前帮人排查过一个问题，数据库里的量表标题全部显示成“???”，最后发现是创建数据库时用了默认的latin1字符集。

3.2 配置文件的核心坑位：多环境配置与数据库连接

一个能直接跑起来的项目，application配置基本决定了成败。部署文档里通常会给两种环境：本地开发环境和生产环境。推荐的做法是用application.yml作为公共配置，再用application-dev.yml和application-prod.yml做环境区分，启动时通过--spring.profiles.active=dev或prod指定。

生产环境的数据库连接配置要特别注意几点。第一，密码不要用明文写死在配置文件里，课程设计阶段可以用，但如果你愿意花十分钟把密码改成环境变量注入，答辩时会明显不一样。第二，连接池参数要显式配置，连接超时时间和最大活跃连接数，不然高峰期并发一上来，数据库连接直接打满。第三，时区问题必须处理，URL里的serverTimezone=Asia/Shanghai一定要有，否则日期字段会在数据库和Java之间来回错8小时。

一个常见的启动报错是Access denied for user 'root'@'localhost'，先别急着检查Java代码，用命令行工具连一下数据库，确认账号密码是否有权限。MySQL 8.0默认的加密规则是caching_sha2_password，有些较老的数据库驱动不支持，需要在驱动URL里加allowPublicKeyRetrieval=true，或者把用户的加密规则改回mysql_native_password。这两种方案都不难，但不知道的人会折腾很久。

3.3 前后端打包与服务器上线

部署阶段的重点在于理解前后端分离的产物发布方式。后端打包成可执行jar包，前端打包成纯静态文件，最后用Nginx把两部分串起来。

后端打包很简单，在项目根目录执行：

mvn clean package -DskipTests

打包完成后在target/目录下会生成psychology-0.0.1-SNAPSHOT.jar。生产环境启动时不建议直接java -jar放前台跑，要用守护方式：

nohup java -jar psychology-0.0.1-SNAPSHOT.jar \ --spring.profiles.active=prod \ --server.port=8080 \ > app.log 2>&1 &

这里我建议把日志输出到指定文件，不然后面排查问题的时候连报错信息都找不到。如果要设置开机自启，用systemd写个service文件更规范，课设阶段简单用nohup也够用了。

前端构建需要进入前端目录（一般是frontend或vue-front），执行：

npm install npm run build

构建完成后会在dist/目录生成静态文件。把dist目录里的所有文件上传到服务器的/usr/share/nginx/html目录，然后配置Nginx反向代理：

server { listen 80; server_name your-domain.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

这里的try_files $uri $uri/ /index.html;极其关键，vue-router用了history模式后，刷新页面时如果直接请求某个子路由路径，Nginx会返回404，加上这行配置后所有请求都回退到index.html，由前端路由接管。少了这一行的部署文档基本都是坑人的。

部署完成后还有一个容易忽略的步骤——防火墙和安全组。云服务器上要在安全组规则里放行80端口和8080端口，否则浏览器访问不了。如果你同时开了服务器自带防火墙，记得执行sudo systemctl stop firewalld或者放行对应端口。每次我远程帮人排查部署问题，十个里面有八个是安全组没开，不是代码问题。

4. 常见问题与排查心得实录

4.1 前端访问8080端口报跨域错误

前后端分离项目，跨域问题几乎是必踩的坑。前端跑在dev模式下的http://localhost:8081，后端跑在http://localhost:8080，端口不同，浏览器的同源策略就会拦截请求。

解决办法有两种。如果你用Vue CLI的devServer，可以在vue.config.js里配置代理，让前端请求转发到后端，这样浏览器看到的是同源请求：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }

另一种方案是在后端配置全局跨域。SpringBoot里实现起来很简单，写一个配置类实现WebMvcConfigurer的addCorsMappings方法，允许http://localhost:8081来源的请求。两种方案选一种即可，不需要同时配置，同时配置反而可能出现请求被拦截两次的问题。

4.2 MyBatis-Plus分页查询失效

分页是管理后台的常见需求，但MyBatis-Plus的分页插件需要手动注入。如果不加这个配置类，你写的selectPage方法会把所有数据查出来，分页效果完全失效：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

这个配置类缺失导致的症状很隐蔽：前端请求pageNum=1&pageSize=10，后端返回的total字段是全部数量，接口数据里却包含了所有记录，页面上的分页组件看起来一切正常，但数据量一大就会严重拖慢查询速度。遇到这种问题，优先检查拦截器是否注册成功，这是最常见的根因。

4.3 部署后刷新页面404

这个问题我在3.3里提过，但因为它太常见，值得再单独拎出来强调一次。vue-router开启history模式后，刷新/student/dashboard这种深层次路由时，Nginx会在磁盘上寻找对应的物理文件，找不到就返回404。解决办法就是配置try_files回退到index.html。如果你看到部署文档里只写了location /root配置而没有try_files，多半是作者没踩过这个坑，或者只用了hash模式。

另外注意，如果部署在二级路径下，比如http://ip:8080/psychology，那么前端构建时也需要配置publicPath为/psychology/，否则资源路径会全部指向根目录，同样找不到文件。这个细节在部署文档里容易被忽略，但实际部署时几乎必然遇到。

4.4 心理健康评测数据的安全与准确性

最后聊一个容易被技术忽视但很重要的问题：心理健康评测系统涉及的数据比较敏感，代码和部署上要多考虑两层。第一层是访问控制，评测结果只能由本人和授权老师查看，管理员角色要限制好，不能所有人都有全量数据权限。第二层是隐私，前后端传输建议使用HTTPS，虽然课程设计阶段通常只是http跑了，但至少要在答辩时能说出这个意识。

还有一个容易被忽略的点是评测结论的措辞。系统生成的“中度抑郁”“重度焦虑”这类结果，前端展示时要加上“评测结果仅供参考，不构成医疗诊断，如有需要请咨询专业心理医生”之类的提示。这个细节在前期需求分析时可能没人提，但如果做出来，无论从产品角度还是答辩角度都是明显的加分项。

4.5 常见问题速查表

5. 把项目能力延伸出去：后续可以加的几个模块

如果你做完这个系统还有余力，或者想让它更“完整”、更有答辩亮点，我给你几个后续扩展的方向。

第一个是Excel批量导入量表题目。后端提供一个接口，接收Excel文件，解析后批量插入题目表和选项表。这个需求在实际使用中几乎必然出现，一份量表几十道题，手工录入既慢又容易错。实现方式也不复杂，用Apache POI或者EasyExcel读取表格，校验字段合法性，再循环插入数据库即可。

第二个是评测趋势可视化分析。学生端展示历次评测得分的折线图，老师端展示班级维度的雷达图或柱状图。这部分前端用ECharts，后端提供聚合查询接口，难度不大，但对系统的完整度和美观度提升非常明显。

第三个是消息通知。当评测结果达到某个阈值时，系统自动给对应老师发送消息提醒。可以用SpringBoot整合WebSocket，也可以简化为在系统内部做一个站内消息列表，实现定时扫描评测结果，触发阈值判断后写入消息表。这个模块如果做出来并能在答辩时演示，印象分会很不一样。

这些模块的共同点是业务逻辑清晰、技术实现成熟、独立性强，可以分开单独做，也能组合起来形成完整闭环。项目本身不难，但能做到这个程度，就已经超出了大部分课程设计的预期。

6. 写在最后的实际操作体会

这套系统我前后看过不少版本，也帮人调试过很多次，最大的体会是：SpringBoot课设项目的成败，不在于用了多少高深技术，而在于能不能把一条完整的链路跑通并讲清楚。从数据表设计到后端接口，从接口联调到部署上线，每一步都会遇到具体的坑，这些坑恰恰是学习的价值所在。

如果让我给一个学习顺序的建议：先跑通代码，再读懂代码，最后才是改代码。很多人拿到项目第一反应是先改功能、加页面，结果后端都还没跑起来，前端调了一堆接口全部报错，这才是最打击信心的。建议先把环境配好、把代码完整运行一次，用Postman测试一遍所有接口，然后再动手去改。

最后一个细节：线上部署的时候，日志一定要留好。nohup启动时把output重定向到文件，这是一个可以帮你省一夜的工具习惯。遇到线上问题，日志里通常会有第一手答案，比对着页面猜来猜去有效得多。