微信小程序+Java后端：青少年心理健康科普平台开发详解

简介：一套基于微信小程序与Java后端（SSM+MySQL）的青少年心理健康科普平台毕业设计资料包，面向毕业设计、课程设计及项目实战开发者，覆盖小程序端与后台管理端完整闭环。系统功能包括：用户注册验证后登录，浏览心理健康知识；心理医生列表展示与详情查看，填写咨询后医生端可查看并回复；‘我的’模块支持个人信息修改与重新登录；管理员管理用户、健康信息、系统配置，并向小程序端发布公告。压缩包含1458个文件、约33.49MB，以Java源码（144个）、Vue页面（152个）、JS逻辑（207个）、小程序WXML/WXSS（约200个）为核心，同时包含数据库SQL脚本2个、图片素材（png/jpg等）、说明文档（docx/md/txt）及演示视频mp4，并附安装、运行、构建批处理脚本，可快速导入微信开发者工具与后端IDE运行。已有269人学习浏览，适合需要完整项目案例、尤其希望掌握前后端联调与后台管理功能的学生参考。

1. 这项目不是「文章阅读小程序」：真正拿分的是测评预警链路

拿到「基于微信小程序+java后端的青少年心理健康科普平台」这个毕业设计源码包，很多人第一反应是：这不就是个文章列表加详情页的小程序吗？但真正让答辩老师坐直身子的，不是页面效果，而是「科普阅读 → 心理测评 → 风险预警 → 预约咨询」这条数据链路是否完整闭环。这个项目的本质是一个前后端分离的微信小程序项目实例：小程序端负责科普内容展示、测评答题和预约交互，Java 后端（Spring Boot 风格）提供接口、计算测评结果并管理业务数据，MySQL 负责所有业务落库。适合两类人：一是把「微信小程序 + Java 后端」作为毕设题目的学生，二是想用最短路径跑通小程序全栈项目的开发者。下面按拿到源码后如何理解、如何跑通、如何改动、如何演示的顺序展开。

2. 小程序端怎么拆：四个页面、两种身份和一套请求层

小程序端最容易犯的错是一上来就贴页面代码。先把目录结构和业务边界理清楚，后面写代码才有方向。这个项目的页面看着多，其实只有四条线：内容展示、测评、预约、个人中心。对应到 pages 目录，就是首页、文章详情、测评列表、答题页、测评结果、预约列表、预约表单和「我的」。

2.1 页面结构与业务边界：别把科普平台做成博客

先分清两种身份：访客和登录用户。访客能看到首页和文章详情，但点进测评或预约时必须先登录。这个边界要在前端提前拦住，不能等后端返回 401 再跳登录。

注意「测评结果」和「答题页」是分开的。提交测评后后端返回一个 recordId，前端拿到 recordId 再跳转结果页。这样刷新结果页、分享结果给他人都有独立的 URL 可访问，不用在答题页里同时维护提交和展示两套状态。

这里不推荐在小程序端引入复杂的状态管理库。原因很简单：页面层级浅、数据流单一，原生 Page 里 setData 完全够用。引入 Vue 或 Redux 那套反而会在答辩时被追问「为什么不用原生」，到时候很难自圆其说。原生 WXML + JS 写完整个小程序，代码量也就是两三千行，维护成本完全可控。

2.2 请求封装：先写 utils/request.js，再写页面

新建页面之前，一定要先写统一的请求层。否则每个页面都裸调 wx.request，token 失效、网络异常、业务错误三种情况要在十几个地方重复处理，后期加一个接口就要复制粘贴一次。常见的做法是封装一个 Promise 风格的 request 方法：

// utils/request.js const BASE_URL = 'http://localhost:8080/api' const TOKEN_KEY = 'psy_token' function request(path, options = {}) { return new Promise((resolve, reject) => { const header = { 'Content-Type': 'application/json' } const token = wx.getStorageSync(TOKEN_KEY) if (token) { header['Authorization'] = 'Bearer ' + token } wx.request({ url: BASE_URL + path, method: options.method || 'GET', data: options.data || {}, header, timeout: 10000, success(res) { // 约定后端统一返回 {code, msg, data}，code=0 表示成功 if (res.statusCode === 200 && res.data.code === 0) { resolve(res.data.data) } else if (res.statusCode === 401 || res.data.code === 401) { // token 失效，清理本地登录态并跳转登录页 wx.removeStorageSync(TOKEN_KEY) wx.navigateTo({ url: '/pages/login/login' }) reject(new Error('登录已过期')) } else { wx.showToast({ title: res.data.msg || '请求失败', icon: 'none' }) reject(new Error(res.data.msg || '请求失败')) } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }) reject(err) } }) }) } module.exports = { request, TOKEN_KEY }

这段代码有三个关键参数：BASE_URL、timeout、以及 code 字段的判定逻辑。BASE_URL 在本地联调时写http://localhost:8080/api，但真机预览必须改成电脑的局域网 IP，比如http://192.168.1.101:8080/api。timeout 设 10 秒，测评提交和结果查询的接口都够用，但如果后面加了文件上传类的功能，单独给那个请求放宽到 30 秒。401 的统一处理是整个封装最值钱的地方——所有页面共用一套「登录过期就踢回登录页」的逻辑，不用每个页面写一遍。

2.3 登录态与缓存：wx.login 拿 code，后端换 token

这个项目的登录流程用的是微信生态里最常见的 code 换 token 模式。小程序端调用 wx.login 拿到一次性 code，发给后端，后端用 code 换取 openid，生成 token 返回给前端。前端把 token 存进 storage，后续所有请求带上它。

// utils/login.js const { request, TOKEN_KEY } = require('./request.js') function login() { return new Promise((resolve, reject) => { wx.login({ success(res) { if (res.code) { request('/auth/login', { method: 'POST', data: { code: res.code, nickname: '访客' + (Date.now() % 10000) } }).then(data => { // 设置缓存时间：token 和过期时间一起写入 storage const EXPIRE_DAYS = 7 wx.setStorageSync(TOKEN_KEY, data.token) wx.setStorageSync('psy_token_expire', Date.now() + EXPIRE_DAYS * 24 * 3600 * 1000) resolve(data) }).catch(reject) } else { reject(new Error('wx.login 获取 code 失败')) } } }) }) } module.exports = { login }

关于「微信小程序设置缓存时间」，很多人以为 wx.setStorage 可以传一个过期时间参数，其实原生 storage 没有这个能力。常规做法就是像上面这样，手动存一个过期时间戳，在 request.js 读取 token 之前先判断Date.now()是否超过了psy_token_expire。超了直接清理并跳登录页，这样 token 过期不用等后端返回 401，前端就能提前判断。

测评页和结果页都复用了这套请求层。测评页提交答案时调用request('/assessment/submit', { method: 'POST', data: { scaleId, answers } })，拿到返回的 recordId 后跳转结果页；结果页再用request('/assessment/record/' + recordId)拉详情。两个页面加起来不到 300 行代码，核心逻辑全部被 request 层承接了。

3. Java 后端按服务切分：Spring Boot 接口设计的实际写法

后端部分是这个项目里最容易被高估难度、也最容易被低估工作量的一块。说难度不高，是因为它本质就是 CRUD 加一个测评计分算法；说工作量不小，是因为接口设计、权限控制、异常处理这些「看不见的东西」才是答辩时老师真正会追问的地方。

3.1 工程结构：为什么毕设不要写上帝 Controller

很多毕设后端只有一个 Controller，几百行代码把文章、测评、预约全部塞进去。这种「上帝 Controller」写法在演示时看不出问题，但答辩老师只要问一句「如果我要新增一个咨询师模块，你动哪些文件」，答不上来就露怯了。常见做法是按业务模块分包：

com.example.psy/ config/ # WebConfig、CorsConfig、拦截器注册 controller/ # ArticleController、AssessmentController、AppointmentController service/ # ArticleService、AssessmentService、AppointmentService mapper/ # MyBatis-Plus 的 Mapper 接口 entity/ # User、Article、Scale、AssessmentRecord、Appointment common/ # Result、PageParam、BusinessException

这个结构适合微信小程序 + Java 后端的毕设体量。controller 层只做参数接收和结果封装，service 层放业务逻辑，mapper 层管数据库操作。这样拆的好处是：答辩时老师问「测评结果怎么算的」，你直接说在 AssessmentService 里；问「预约怎么校验冲突」，你在 AppointmentService 里讲。代码在哪一层，你心里有底，老师也听得明白。

后端的技术栈里只需要 Java 基础里的集合、循环、Map 操作，加上 Spring Boot 的注解就能跑起来，不需要引入工作流引擎、消息队列这些重武器。保持简单，才是毕设该有的样子。

3.2 测评结果计算：Controller 只做转发，业务进 Service

测评模块是整个项目里唯一有「算法感」的地方，也是最值得在答辩时展开讲的亮点。业务流程是这样的：前端提交量表 ID 和答案数组，后端根据量表配置逐题计分、计算总分和维度分、划分风险等级、存入测评记录表，最后返回 recordId。

@RestController @RequestMapping("/api/assessment") public class AssessmentController { private final AssessmentService assessmentService; public AssessmentController(AssessmentService assessmentService) { this.assessmentService = assessmentService; } @PostMapping("/submit") public Result<Long> submit(@RequestBody SubmitRequest req, @RequestAttribute("userId") Long userId) { // 只做参数校验，不做业务判断 if (req.getScaleId() == null || req.getAnswers() == null || req.getAnswers().isEmpty()) { return Result.error("量表 ID 和答案不能为空"); } Long recordId = assessmentService.submit(userId, req.getScaleId(), req.getAnswers()); return Result.ok(recordId); } @GetMapping("/record/{recordId}") public Result<AssessmentResultView> record(@PathVariable Long recordId, @RequestAttribute("userId") Long userId) { return Result.ok(assessmentService.getResult(recordId, userId)); } }

提交接口只做一件事：校验参数合法后转给 Service，返回 recordId。前端拿这个 ID 再去请求结果详情，避免一次提交返回太多字段导致网络包过大。@RequestAttribute("userId") 来自拦截器解析 token 后的注入，Controller 完全不用关心 token 是怎么来的，职责自然分离。

SubmitRequest 的参数结构如下：

Service 层做真正的计分逻辑：

@Service public class AssessmentService { public Long submit(Long userId, Long scaleId, List<Integer> answers) { // 查量表配置，题目选项和维度映射都存在 scale 表中 Scale scale = getById(scaleId); int total = 0; Map<Long, Integer> dimensionScore = new HashMap<>(); for (ScaleQuestion q : scale.getQuestions()) { int optionIndex = answers.get(q.getOrderIndex()); int score = q.getOptionScore(optionIndex); total += score; dimensionScore.merge(q.getDimensionId(), score, Integer::sum); } // 风险等级：0-正常，1-轻度，2-预警 int level = total < scale.getMildThreshold() ? 0 : total < scale.getModerateThreshold() ? 1 : 2; AssessmentRecord record = new AssessmentRecord(); record.setUserId(userId); record.setScaleId(scaleId); record.setTotalScore(total); record.setLevel(level); record.setDimensionJson(JSON.toJSONString(dimensionScore)); save(record); return record.getId(); } }

这段代码的关键点有两个。第一，维度得分独立计算并存入 dimension_json 字段，这样结果页可以按维度展示解释文本，而不是只给一个总分。第二，level 用 0/1/2 三个整数表示，前端和后端共用这一套枚举，避免字符串比较带来的大小写和拼写问题。

这里要特别说明为什么把维度得分存 JSON 而不是拆一张维度明细表：毕设体量下，多一张表意味着多一套 Mapper、多一套 Service、多一段前端渲染逻辑，但测评后要做的是「按维度和总分产出解释文本」，JSON 足够支撑。生产系统才需要拆表做统计分析，毕设场景优先保证链路简洁。

3.3 权限控制：拦截器统一入口，Service 层管业务权限

后端不能让每个接口自己判断「当前用户是谁」，否则代码里全是重复的 token 解析逻辑。常规做法是在拦截器里统一解析 token，注入 userId，业务层再按需判断。

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) { String auth = req.getHeader("Authorization"); if (auth != null && auth.startsWith("Bearer ")) { Long userId = JwtUtil.parse(auth.substring(7)); if (userId != null) { req.setAttribute("userId", userId); return true; } } resp.setStatus(401); return false; } }

拦截器里只做一件事：解析 token，注入 userId。至于这个用户能不能查某条测评记录、能不能改某个预约，是 Service 层的业务权限，不需要在拦截器里判断。很多毕设把权限判断全堆在拦截器里，导致拦截器越写越长，改一处权限就要动全局，非常痛苦。

拦截器注册时要注意放行路径。首页文章列表、文章详情这些「访客可访问」的接口要加进白名单：

registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/api/**") .excludePathPatterns("/api/article/**") .excludePathPatterns("/api/auth/login");

另外记得配置跨域。小程序端不算浏览器跨域场景，但如果你用 Swagger 调试接口，或者后续想做个网页管理端，跨域配置能省不少事。CorsConfig 里 allowedOriginPatterns 用*就行，毕设环境不需要把域名写死。

4. 数据库设计与联调：五张表和一个 JSON 字段

数据库是这个项目的数据地基。压缩包里的数据库脚本能不能跑通、表结构合不合理，直接影响前后端联调节奏。很多毕设翻车不是代码写不出来，而是表设计的时候少了一个字段，联调阶段来回改接口。

4.1 五张核心表：用户、文章、量表、测评记录、预约

这个项目最精简的表结构是五张表：user、article、scale、assessment_record、appointment。article 是科普文章，scale 是测评量表配置，assessment_record 是用户的测评结果，appointment 是预约咨询记录。

CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) UNIQUE NOT NULL, nickname VARCHAR(32), avatar_url VARCHAR(255), role TINYINT DEFAULT 0 COMMENT '0-用户 1-管理员', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE article ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL, category VARCHAR(32), content LONGTEXT, cover_url VARCHAR(255), view_count INT DEFAULT 0, published TINYINT DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE scale ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, description VARCHAR(255), question_json LONGTEXT COMMENT '题目、选项、维度映射配置', mild_threshold INT COMMENT '轻度风险阈值', moderate_threshold INT COMMENT '中度风险阈值', status TINYINT DEFAULT 1 ); CREATE TABLE assessment_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, scale_id BIGINT NOT NULL, total_score INT, level TINYINT COMMENT '0-正常 1-轻度 2-预警', dimension_json JSON COMMENT '维度得分明细', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_created (user_id, created_at) ); CREATE TABLE appointment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, consultant VARCHAR(32), appointment_time DATETIME, status TINYINT DEFAULT 0 COMMENT '0-待确认 1-已确认 2-已完成 3-已取消', note VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP );

几个设计细节说一下。user 表的 openid 必须加 UNIQUE 约束，这是微信侧的用户唯一标识，重复会导致同一个人产生多个账号。article 的 content 用 LONGTEXT，心理科普文章写几千字很常见，VARCHAR(255) 根本放不下。assessment_record 里的 level 字段是核心，前端展示和后续统计都依赖它。

还有一个容易被忽略的决策：全部不建外键。这个做法是故意的——如果建了外键，删除文章时测评记录的处理会变得非常麻烦。表之间只保留逻辑关联，不建物理外键，谁都不影响谁，数据由 Service 层保证一致性。这个思路在答辩时可以主动讲出来，比被老师用外键问题「卡住」要主动得多。

4.2 测评记录用 JSON 存储还是关系表：毕设场景的选型

dimension_json 字段是争议点。拆成一张 dimension_score 明细表更「正规」，但代码量和接口复杂度都会上升。在毕设这个场景里，用 JSON 是成本和收益最平衡的方案。

原因有三。第一，维度得分只是结果页展示用，不做统计筛选；第二，量表的维度配置基本不变，不存在增删改维度后还要维护历史数据的问题；第三，前端结果页只需要一个JSON.parse就能拿到全部维度得分，不需要联表查询。

注意：JSON 字段不要参与复杂统计。如果后面要做「所有用户焦虑维度均值」这类分析，应该单独建维度明细表。毕设阶段如果被问到这一点，承认这是简化方案并说明生产系统怎么改，比硬撑「JSON 更好」更能拿分。

4.3 前后端联调对齐的三个点：时间格式、分页参数、响应体

前后端分离项目最常见的问题不是逻辑不对，而是两端的「约定」不一致。时间格式、分页参数、响应体就是最典型的三个坑。

时间格式：Spring Boot 默认序列化 LocalDateTime 会输出2025-06-01T12:00:00这种 ISO 格式，小程序端new Date()在 iOS 上解析带 T 的字符串会直接返回 Invalid Date。后端要全局格式化：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai

分页参数：列表接口统一用page和size两个参数，返回体统一是{ total, list }。不要一个接口用 pageNum/pageSize，另一个接口用 current/limit，前端封装分页组件时会非常痛苦。

响应体：后端统一返回{ code, msg, data }，前端 request.js 只认这一种结构。code 为 0 表示成功，401 表示登录失效，其他值都是业务错误。三个对齐项在联调前写进接口文档里，前后端照着同一份约定做，能省掉一半联调时间。

5. 避坑：从环境到部署的五个真实翻车场景

拿到压缩包先别急着跑，先按顺序做三件事：读说明文档里的环境要求、导入数据库脚本、看演示视频里用的端口号。这个顺序能避开大量「为什么我跑起来是白屏」的问题。下面五个坑是我见过的高频翻车点，每一条都是真实发生过的。

5.1 真机请求失败，但开发者工具一切正常

现象：开发者工具里接口全部正常，一点预览或体验版，所有 wx.request 都报request:fail。

原因：小程序真机环境校验 request 合法域名，本地接口是http://192.168.x.x:8080这种地址，既不是 https，也不在白名单里。开发者工具默认勾选了「不校验合法域名」，所以本地跑得欢，一到真机就露馅。

解决：开发阶段在开发者工具的「详情 → 本地设置」里勾选「不校验合法域名」，真机预览时在手机端小程序右上角菜单里打开「调试」模式，http 请求才能放行。正式演示如果要用体验版二维码，后端必须挂到已备案的 https 域名，并且在小程序后台把域名加进 request 合法域名白名单。最稳妥的做法是答辩前一周就把域名备案这件事推进完，不要在答辩前一天才想起来。

5.2 测评总分正确，维度解释文本错位

现象：量表总分算对了，但结果页「情绪低落」维度的解释文本显示在了「焦虑倾向」下面。

原因：维度解释的渲染顺序和量表题目配置的维度顺序不一致。一般是因为前端结果页硬编码了维度的展示顺序，而后端 dimension_json 里 Map 的遍历顺序不保证和插入顺序一致，两边各排各的，一错位就是整列错位。

解决：维度解释不要用数组下标对应。在 scale 表的 question_json 里给每个维度配一个order字段，后端计算 dimension_json 时按 order 排序，前端渲染前同样按 order 排序。两端都用同一个 order 字段作顺序依据，谁也不会错。

5.3 数据库时间比本地时间差 8 小时

现象：本地在下午 3 点提交一条预约，数据库里记录的 created_at 变成早上 7 点。

原因：JDBC 连接串里没有指定 serverTimezone，MySQL 驱动用了服务器默认时区来解析时间，导致时间偏移 8 小时。这个坑在 Windows 上最隐蔽，因为本地开发环境时区通常是对的，换到 Linux 服务器部署时才暴露。

解决：JDBC 连接串显式指定时区：

jdbc:mysql://localhost:3306/psy?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

同时在数据库连接层面把 time_zone 也设为+08:00。改完重启后端服务，再测一次时间写入和读取是否一致。

5.4 JAR 包启动报「找不到主类」

现象：mvn package成功，但java -jar psy.jar启动时报错，提示no main manifest attribute或找不到主类。

原因：父级 pom 里没有引入 spring-boot-maven-plugin，或者引入了但没执行 repackage goal。打包出来的是一个普通 JAR，Spring Boot 的启动类没有写进 MANIFEST 文件，自然找不到入口。

解决：在 pom.xml 里加上：

<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>

重新执行mvn clean package，看到控制台输出「repackage」字样，再查看 target 目录里 JAR 的大小。Spring Boot 可执行 JAR 通常在 30MB 以上，如果打包出来只有几百 KB，基本就是没配成功。

5.5 演示时白屏，打开调试发现 token 校验失败

现象：前一天演示还好好的，第二天打开小程序直接白屏，后台日志一堆 401。

原因：小程序端 storage 里还留着昨天的 psy_token，后端 JWT 秘钥或者 token 有效期已经变了，前端拿着过期 token 去请求接口，被拦截器拦下来返回 401，前端又没有做「登录过期跳转」的处理，白屏就出现了。

解决：演示前手动清一次小程序缓存，或者在小程序「我的」页面加一个「清除缓存」按钮，把 storage 里的 token、过期时间、临时数据全清掉，然后重新走一遍「登录 → 测评 → 结果」流程。演示前把这个动作当成例行步骤，比现场想办法解决快得多。

6. 不知道怎么讲的话：把「测评→预警→人工介入」这条链路演示出来

很多同学功能做完了，演示时却不知道先点哪里。其实这个项目的演示有一条天然的主线：首页看科普内容 → 做一份心理测评 → 结果页触发预警提示 → 跳转预约咨询。这条链路的每一步都有前端交互、后端接口和数据落库，「内容 + 数据 + 状态流转」三件事讲清楚了，答辩就成功了一大半。

6.1 一分钟演示脚本

打开小程序，先在首页点开一篇科普文章，讲前端如何从 article 接口拉取内容并渲染；然后进入测评列表，选择一份量表，快速完成答题；提交后跳转结果页，此时要指着屏幕说「这里显示了总分、维度得分和风险等级」，如果 level 为 2，页面会展示「建议预约专业咨询」的提示；接着点预约按钮，选择咨询师和时间，提交预约；最后切到「我的」页面，展示测评记录和预约状态的变化。

每做一步，都用一句话说明数据从哪里来、存到了哪里。例如做完测评后说：「这里前端把答案数组 POST 到 /api/assessment/submit，后端计算完总分写入 assessment_record 表，再把 recordId 返回给前端，结果页通过 recordId 拉详情。」这样一段话说下来，比背十页论文有效得多。

6.2 演示前必查的三个自测点

最后说一个我自己的习惯。每次演示前，我会把这条链路完整走三遍：第一遍看功能有没有报错，第二遍看数据库落库是否符合预期，第三遍只看数据流的每一步能不能用一句话讲明白。翻车大多不是功能没写完，而是演示时不知道第一句话说什么。这个项目的核心价值不在页面好看，而在数据能跑通一条有社会意义的链路——科普、测评、预警、预约介入，每一步都有迹可循。希望帮到你。

本文还有配套的精品资源，点击获取