企业官网建设流程全解析

这个项目是我去年帮某市未成年人心理健康指导中心搭的一套Spring Boot系统，代号i13zo。名字没什么含义，就是项目仓库随机生成的短码，结果一用就是大半年。整套系统围绕“测评-预警-干预”三个环节展开，面向中小学生、心理老师、咨询师和家长，核心就一句话：把散落在纸质问卷和Excel里的心理测评数据，变成一套能自动预警、能流转个案、能追踪干预效果的工作台。

做这类系统的难点不在CRUD，而在于你怎么让不同角色都觉得这工具“有用”。学生端要足够简单，几道题点完就行；心理老师端要看得到分级预警，能批量处理；咨询师端要有完整的个案时间线；家长端则只能看到脱敏后的建议，不能看到孩子原始得分。这篇文章我就把这个系统的设计思路、核心表结构、关键实现和部署调试过程完整拆一遍，代码细节会讲，但更侧重讲清楚“为什么这么做”。如果你正在做心理健康类管理系统，或者准备用Spring Boot做一套多角色业务系统，这篇应该能让你少踩不少坑。

1. 项目立项背景与需求拆解：谁会用到这套系统

1.1 “心理测评麻烦”到底是什么

很多学校每学期都要做一轮心理普查，但传统做法是打印纸质问卷、学生填卡、老师手工录入Excel，再按总分排序筛出异常学生。一套流程走下来至少两三个星期，等结果出来，有些预警早就错过了最佳介入时间。

我接手这个项目时，中心提了几个明确诉求：第一，测评必须支持电脑和手机双端，学生能扫码直接答；第二，系统不能只记录分数，要能按量表维度自动出报告；第三，发现中高风险学生后，要能一键生成干预工单，后续谁跟进、做了什么、效果如何都得留痕；第四，所有数据要分级查看，家长不能看到孩子原始答题内容。

这些诉求拆解下来，其实就是一套标准的多角色管理系统：基础数据维护、在线测评、自动计分与预警、个案的咨询预约与过程记录、数据统计看板。用Spring Boot做后端是非常顺手的选择，社区成熟、生态完善，招人也好招，后续维护成本低。

1.2 核心模块划分与角色权限

我习惯在写代码前先画业务模块图，心里有全景图，代码才不会写乱。i13zo的整体模块划分如下：

• 系统基础模块：组织架构（学校、年级、班级）、用户账号、角色权限、菜单管理。
• 测评中心模块：量表管理、题目维护、测评任务发布、答题记录、测评报告生成。
• 预警干预模块：风险等级规则、预警记录、个案工单、干预记录、转介记录。
• 咨询预约模块：咨询师排班、预约单管理、咨询记录、满意度回访。
• 数据中心模块：测评完成率、风险分布、预警趋势、干预完成情况等统计看板。

角色权限这块，我最终定了四类角色：系统管理员、心理老师、咨询师、家长/学生端（学生端轻量，只做答题和查看自己的报告；家长端只查看孩子完成测评情况和经过脱敏处理的建议）。

这里有个设计细节值得说一下：学生账号不搞独立注册，而是由系统管理员或班主任批量导入。未成年人隐私保护要求很高，如果让学生自己注册，账号审核和实名认证都是麻烦事。批量导入后，学生通过学号或者班主任下发的临时码登录，数据从一开始就和真实身份绑定，测评结果不至于张冠李戴。

1.3 技术路线选型：为什么是Spring Boot 3

技术栈选择上，前后端分离是明确的方向。后端用Spring Boot 3.2.x，搭配Java 17；持久层用MyBatis-Plus，省去大量单表CRUD代码；数据库用MySQL 8.0；缓存用Redis；前端用Vue 3 + Element Plus，打包后由Nginx托管。

Spring Boot 3相比2.x最大的变化是javax包名改成了jakarta，刚迁移时会有一些老依赖不兼容，但只要项目是新开的，直接用3.2反而省心，后续依赖升级也顺畅。Java 17的虚拟线程在JDK 21里才更成熟，所以17对我来说是稳妥选择，编译产物体积小，内存占用也低，适合部署在云服务器上。

Redis主要用来缓存两样东西：量表的题目配置和用户的会话状态。心理测评量表的题目很少频繁变动，每次答题都查数据库完全没有必要。Redis按量表ID缓存题目列表，学生端打开测评页面时直接走缓存，响应时间基本在100毫秒以内。分布式会话则用Spring Session结合Redis实现，这样后期如果部署多台服务器，登录状态也不用重新设计。

提示：如果不是对技术栈有特殊执念，遇到这类管理系统不要自己造轮子。Spring Boot + MyBatis-Plus + MySQL的组合，网上资料多、踩坑答案全、招人也好招，这是选型时最实在的考量。

2. 架构设计与数据库建模：先让数据关系干净起来

2.1 项目目录结构怎么组织

包结构直接决定你后续写代码的时候能多快定位问题。我按业务域划分包，而不是按技术类型划分。

com.i13zo ├── common // 通用工具、异常处理、统一返回体 ├── config // 配置类：Redis、安全拦截、异步线程池 ├── controller // 接口层 ├── service // 业务层接口与实现 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体 ├── dto // 入参出参对象，不直接暴露实体 ├── enums // 业务枚举，比如风险等级、测评状态 └── task // 定时任务：测评任务过期、预警去重

这种组织方式的好处是，拿到一个需求，你知道新代码该往哪个包塞；出了问题，也基本能按照“请求→controller→service→mapper”的路径快速排查。千万别按controller、service、entity三层包名一拖到底，项目一复杂整个目录就成了一锅粥。

2.2 核心数据表设计与关系说明

数据库设计是这类系统的重中之重，表结构要能支撑业务扩展，又不能过度设计。我梳理下来的核心表大致有这些：

在设计时有两个地方我调整过多次。一是答题明细和测评结果的拆分，答题明细只存每道题的原始选项，测评结果则存总分、维度分和风险等级。这样做的原因是，测评报告需要反复展示，每次现算十几道题的分数虽然性能也不差，但没必要；而且量表后续可能调整题目，结果必须按“当时的评分规则”固化下来。

二是预警记录和个案工单的分离。很多类似系统把预警和个案混在一张表里，但我建议拆开。预警记录是系统自动生成的，属于事实；个案工单是人工处理的，属于事务。心理老师收到预警后可能决定暂不干预，也可能发起一个长达数月的个案跟踪，这两者的生命周期完全不同，拆开才能各自独立流转。

2.3 权限模型与数据隔离

未成年人心理健康数据非常敏感，权限设计如果偷懒，上线后就是事故。我采用的是RBAC模型加数据权限范围控制。

RBAC负责“谁能做什么”，数据权限负责“谁能看哪部分数据”。系统管理员能看到全部学校的数据；心理老师默认只能看到自己所在学校的全部数据，跨校数据需要管理员授权；咨询师只能看到分派给自己或者自己预约的个案；家长端通过独立的家长账号绑定孩子，只能查看脱敏后的建议内容。

实现上，数据权限我用了MyBatis-Plus的拦截器，在SQL执行前自动拼上org_id或者doctor_id的条件。比如查询测评任务列表时，后端会拿当前登录用户的组织范围，拼出WHERE org_id IN (...)。这样做比在每一条Service里手写判断条件要安全得多，不会出现某个接口漏写权限条件导致越权。

注意：未成年人数据的安全合规不只是技术问题，更是流程问题。上生产环境之前，我专门做了一轮接口遍历测试，用不同角色登录逐一调用每个接口，确保A角色不能拉取B角色的学生数据。这一步千万别省。

3. 核心功能实现：从测评到干预闭环

3.1 测评量表引擎：配置化才是王道

心理健康测评最大的特点是量表种类多，量表结构还不一样。有的量表是4个维度、20道题，每题1到4分；有的是9道题按0到3计分；还有的涉及反向计分。

第一批需求就涉及三个量表：一个抑郁筛查量表、一个焦虑筛查量表、一个综合心理状态量表。如果不做配置化，每接一个新量表就要写一套计分逻辑，开发效率极低。

我设计的量表引擎很简单：量表配置表维护量表基础信息，题目表维护每道题的所属维度、计分方式、题目顺序。计分逻辑放在一个统一的AssessmentCalculator中，根据量表的scoreType枚举来路由计算方式。

以抑郁筛查量表（我习惯叫D-Scale）为例，9道题，每道0到3分，总分范围0到27分，按总分分四级预警。配置大概是这样的：

scale_code = "DSCALE" score_type = "SUM" # 求和计分 dimensions = [{"code": "DEP", "name": "抑郁维度", "range": "0-27"}] warn_rule = {"0-4": "低风险", "5-9": "中风险", "10-14": "中高风险", "15-27": "高风险"}

当学生提交答卷后，后端服务按量表ID拉取Redis缓存的题目配置，遍历答题记录计算总分和维度分，然后匹配预警规则生成风险等级。这里有个容易被忽略的细节：反向计分题目要单独标记reverse=true，比如某道题是“我感到生活很有意义”，在抑郁量表中就属于反向题，选“完全没有”要计满分，选“几乎每天”要计0分。如果这一条不做配置化，换一个量表就得改代码，后台人员也只能干瞪眼。

整个计算逻辑我写成了纯函数，没有任何数据库查询依赖，入参就是题目定义和答案列表，出参就是总分、维度分和风险等级。这样可以用单元测试把各种边界条件都测一遍，不用启动项目就能保证计分正确。

3.2 预警规则与个案流转：别让风险卡在纸上

系统真正发挥作用的是预警之后的自动流转。学生测评完成后，一旦风险等级达到中高风险及以上，系统会生成预警记录，同时检验同一学生30天内是否已有未关闭个案；如果没有，自动创建一个待处理的个案工单，并推送给学校心理老师。

这里我设置了两个规则：一个叫“周内去重”，就是同一维度的高风险预警在一周内不重复生成工单，避免心理老师一天被同一个学生的预警反复轰炸；另一个叫“转介留痕”，如果心理老师判断个案需要转介给专业咨询机构，必须填写转介原因和目标机构，所有的转介记录都留在时间线里，方便后续追踪。

预警和干预的闭环我画流程想了很久，最终的实现路径是：测评记录产生结果，结果超过阈值产生预警，预警可以被处理为“已关注”或“已转个案”，个案内部继续追加干预记录、咨询记录、回访记录，最后可选择结案并填写效果评估。这个流程的每个节点都记录了操作人、操作时间和操作内容，审计追踪没有任何盲区。

这套流程看起来简单，但代码层面的状态机设计要格外小心。我用了一个状态字段status来控制个案流转，枚举包括：PENDING（待处理）、FOLLOWING（跟进中）、CONSULTING（咨询中）、REFERRED（已转介）、CLOSED（已结案）。状态的扭转统一放在Service层，不允许Controller直接修改状态的接口，前端也只能调用业务语义明确的接口，比如acceptCase、assignCounselor、closeCase，而不是暴露一个泛化的updateCaseStatus接口。这样从根上堵住了乱改状态的问题。

3.3 咨询预约与档案管理：时间线比表格更好用

咨询预约模块的核心是排班和冲突检测。咨询师可以按周设置排班时段，比如每周二下午3点到5点可预约，每个时段30分钟。学生端只能看到“当前可预约”的时段，不能看到排班全貌，更不能看到其他学生的预约记录。

预约冲突检测我直接在数据库层面做了约束：预约表加了counselor_id + appointment_time的唯一索引，插入冲突时MySQL直接报错，再由全局异常处理器翻译成“该时段已被预约”的友好提示。用数据库约束代替代码判断，是我这种怕写多线程的人最喜欢的方式，简单且绝对可靠。

个案档案部分，我没有刻意设计复杂的“档案”概念，而是把每个学生的全部干预记录、咨询记录、测评结果都按时间线聚合展示。咨询师打开一个个案时看到的不只是基本资料，而是一整条时间轴：几月几号做了测评，风险等级是多少，几月几号心理老师做了首次访谈，几月几号预约过咨询，咨询记录的内容概要，干预效果如何。

这个聚合查询在MySQL里做也可以，但数据量大之后会有点吃力。我用的方案是：时间线数据不走实时聚合，而是由一条csl_case_timeline表专门记录事件，业务层在产生测评、预警、干预、咨询等动作时，利用Spring的事务同步事件同时写入时间线表。查询时一条SQL就能把整个时间线拉出来，性能压力很小。

3.4 数据看板与统计口径问题

心理健康系统的数据看板，统计口径极其容易打架。比如“风险学生数”，是取最新一次测评的结果，还是取本学期最差的一次结果？不同口径下数据可能相差很大。

我在做看板之前先和数据中心的老师对齐了口径，最后确定了几条硬性规则：

• 测评完成率：某学校实际提交答卷人数 / 应测人数，应测人数以测评任务发布时选定的组织范围为准。
• 风险分布：以“最近一次测评”的结果为准，按风险等级统计人数。
• 预警趋势：按周统计新增预警记录数，排除一周内的重复预警。
• 干预完成率：已结案个案数 / 总个案数，转介中的个案不算结案。

看板接口的SQL我统一放在独立的统计Mapper里，不走业务Mapper，避免业务逻辑变更影响统计逻辑。第一次上线的时候我统计出来的完成率和中心自己用Excel算的对不上，最后发现原因是应测人数的口径：中心老师是按“全校学生总数”算的，但系统里有些学生属于已毕业或者转校状态，应测人数应该排除这些无效账号。修正校验状态后，数据终于对上了。统计报表上线前，一定要找业务方一起拿真实数据校验一次，这是血泪教训。

4. 本地调试与部署实录：从能跑到能上线

4.1 开发环境准备清单

我用的开发环境如下，新手可以直接照搬：

• JDK 17（我用的是17.0.10）
• Maven 3.9.x
• MySQL 8.0.x（字符集utf8mb4）
• Redis 6.2+
• Node.js 18.x（前端构建用）
• Nginx 1.24（部署前端资源并做反向代理）

克隆代码后，先在本地把后端跑起来，最省事的方式是直接在IDE里启动主类。但有个前提：先改配置文件里的数据库账号密码和Redis地址。

后端核心配置在application.yml里，关键几项包括：

spring: datasource: url: jdbc:mysql://localhost:3306/i13zo_db?useUnicode=true&characterEncoding=utf8mb4&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password redis: host: localhost port: 6379 servlet: multipart: max-file-size: 20MB mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

务必确认字符集是utf8mb4，否则遇到生僻字或者emoji形式的输入会出现乱码或者存储失败。未成年人姓名里生僻字不少，这个细节我当时是在测试阶段发现的，测试组输入了一个名字里带生僻字的虚拟学生，结果页面直接乱码，排查了半天。

4.2 数据库初始化与必要数据准备

项目交付时附带一个schema.sql和data.sql。schema.sql是完整的建表语句，data.sql是初始化数据，包含管理员账号、角色菜单、基础常量字典。

在本地先导入一次干净数据，然后直接用sql_mode保持严格模式：

SET GLOBAL sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

严格模式能拦住很多脏数据，比如日期字段出现0000-00-00这种值，在严格模式下直接报错，开发期就能发现。

初始化数据里要特别注意管理员初始账号的密码。项目默认给了个固定密码，但部署上线前必须强制改掉。我在代码里做了一个逻辑：sys_user表中带is_init_password字段，初始导入的管理员账号该字段置为1，管理员首次登录时后端强制跳到修改密码页面。这个机制不复杂，但能有效防止默认口令被人登录。

4.3 部署到Linux服务器：后端Jar包加前端静态资源

生产环境我采用了很常规的两段式部署。后端打成jar包，用systemd托管；前端构建后的dist目录放到Nginx的html目录下，Nginx配置反向代理把/api开头的请求转发到后端端口。

后端打包命令没什么特殊的：

mvn clean package -DskipTests

打出来的jar包直接放到服务器的/opt/i13zo/目录，systemd服务配置简化如下：

[Unit] Description=i13zo-backend After=network.target [Service] User=www WorkingDirectory=/opt/i13zo ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/i13zo/i13zo-backend.jar Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

这里有几个点要提醒：

• 生产环境一定要配置spring.profiles.active=prod，生产配置里把日志级别调成WARN，不然每天日志能涨几个G。
• JVM参数里-Xmx不要给太大，云服务器内存通常有限，给到够用就行。我这个服务QPS不高，堆内存512M起始、最大1G绰绰有余。
• Nginx配置里，前端和后端共用80端口，按路径分流：

server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/i13zo; index 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; } location / { try_files $uri $uri/ /index.html; } }

try_files配置的关键作用在于，Vue是history路由模式，刷新某个子页面时如果Nginx没有这个配置，会直接404。这个坑我印象很深，第一次上线后同事说页面刷新就白屏，加完这行配置就好了。

5. 常见问题与排查技巧实录

5.1 开发部署阶段最高频的几个问题

下面这张表是项目从开发到上线过程中最常遇到的问题和排查方向，很多问题光看报错信息容易走弯路。

其中最快的排查技巧是统一返回体。我给所有接口返回都包了一层{code, message, data}，并在全局异常捕获里把实际异常信息记录到日志里，响应前端时统一返回“系统繁忙”。这样前端不会看到一堆堆栈，但排查时看后端日志能精确找到问题。

5.2 数据安全与备份：心理健康数据不能丢

心理健康数据的敏感级别比一般业务数据高。我上线前做了一套备份方案：

• MySQL每天凌晨3点全量备份，备份文件保留7天；
• Redis只做缓存，不依赖它做持久化，所以没有单独备份；
• 操作日志表单独按月分表归档，避免单表数据无限膨胀。

备份脚本核心就是mysqldump加日期命名：

mysqldump -u root -p --single-transaction --quick --routines i13zo_db > /data/backup/i13zo_$(date +%Y%m%d_%H%M%S).sql

--single-transaction参数很关键，它保证备份过程中不会锁表，学生在白天做测评也不会因为备份卡顿。

数据脱敏也是必须考虑的。我在查询家长端数据时专门做了一层过滤，家长只能看到孩子的测评结果摘要和已脱敏的建议内容，原始题目答案、每题分数都不展示。这个过滤是在后端Service层做的，而不是依赖前端隐藏字段，前端能拿到什么数据完全由后端决定。

5.3 性能优化的三点经验

这套系统的并发量并不高，一个区几百所学校同时做测评，峰值QPS也就几十，但我在性能优化上还是做了几件事，效果很明显。

第一件事是测评结果批量入库。学生提交答卷后，后端会把答题明细、测评结果、预警记录放在一个事务里批量写入。如果几百个学生同时提交，就不会因为一条一条插入拖垮数据库。批量插入我用的是MyBatis-Plus的saveBatch，内部其实就是一条批量SQL。

第二件事是Redis缓存热点配置。量表配置、测评任务信息、班级学生列表，这些数据读多写少，全走缓存。缓存更新采用主动失效策略：后台修改量表题目后，直接删除对应的缓存key，下次请求自动回源数据库并重建缓存。

第三件事是慢SQL治理。我在项目里开启了MySQL的慢查询日志，阈值设为2秒。上线第一个月就抓到了几条慢SQL，基本都是报表统计时关联了过多表。后来我把统计查询拆成了两次轻量查询，在代码层面做数据装配，速度反而比一条大SQL快很多。

最后分享一点心得

开发这类心理健康系统，技术上最难的往往不是框架，而是你如何把复杂的业务规则理成清晰的技术设计。量表计分方式各不相同，预警规则要分级，个案状态要可控，统计口径要和业务方反复对齐，这些都比写CRUD更消耗心力。我在开发时保持了“一切流程留痕、一切状态可查、一切数据分级”三条原则，后面接手的人维护起来会轻松很多。

另外想说句题外话：测评结果再怎么自动化，最终面对孩子的还是人。系统能做的只是把异常信号及时准确地送到该看的人手里，真正起作用的是心理老师和咨询师的专业判断。我在做预警流转功能的时候特意加了“强制查看干预指引”的弹窗，就是想提醒使用系统的老师，数据是辅助，人才是核心。如果你也在开发类似的项目，记得多和一线使用者聊聊，他们的反馈往往能帮你发现设计里最不合理的那个点。