基于微信小程序云开发的大学生心理健康测评系统设计与实现

写这个系统的这段时间，我最大的感受是：毕业设计最难的地方不是写代码，而是想清楚"这个系统到底为谁解决什么问题"。大学生心理健康测评系统听起来是个老生常谈的题目，但真要落成一个能演示、能答辩、能说清楚技术亮点的项目，需要你把微信小程序前端、数据存储、测评量表、结果判定、隐私安全这些环节全串起来。这篇就把我自己的实现思路和踩坑过程完整拆开讲，给准备做类似题目的同学一条能直接照着走的路。

先交代一下背景：我选的技术路线是微信小程序原生开发 + 微信云开发，也就是不自己买服务器，用云函数、云数据库、云存储来支撑后端。之所以这么做，一是学生党没有太多预算和时间去折腾域名备案和服务器运维，二是云开发的权限体系和免鉴权调用对小程序场景非常友好，三是答辩时"无服务器架构"本身就是个能讲的亮点。测评量表方面选了SCL-90症状自评量表作为核心，同时预留了SAS焦虑量表和SDS抑郁量表的扩展位，这样既能体现专业性，又能展示系统的可扩展设计。

1. 需求拆解与整体设计

1.1 这个系统到底要解决什么问题

先别急着写代码，花两天时间把需求捋清楚比什么都值。大学生心理健康测评这个场景里，真正需要被满足的角色有三个：学生、心理中心老师（或者辅导员）、以及系统管理员。

对学生来说，他们要的是一个低门槛、无压力的自测入口。在手机上交几道题就能拿到结果，不需要去机房填纸质问卷，不需要面对面和心理老师聊。这个过程本身就要减少社交压力，所以"匿名感"和"一键进入"很重要。

对心理中心老师来说，他们要的是测评数据的集中回收和预警提示。很多学校每学期都会做一次全员心理普查，以前靠各班心理委员收纸质表再手工录入，工作量巨大。如果有系统能自动汇总分数、标记出需要重点关注的记录，工作效率能提升一个量级。

对管理员来说，他们要的是量表可配置、用户可管理、数据可导出。量表不是永远不变的，题目顺序、常模标准都可能调整，如果这些写死在代码里，每次改动都要发版，这在真实运营中是灾难。

对应到毕业设计，我建议把功能范围收敛成三个端：小程序用户端负责登录、测评、看结果、查历史；云函数加云数据库承担所有业务逻辑和数据存储；管理后台我用了一个极简的Web页面（也可以用小程序端做管理员功能，但Web可展示性更好）。你不需要做得很臃肿，但每一块都要能跑通闭环。

1.2 功能清单与角色边界

因为我选了云开发，所以"前端小程序 + 云函数 + 云数据库"这套组合里，角色的边界其实很清晰。我把功能拆成下面这些模块，每个模块都对应到具体的页面或云函数。

用户端功能：

• 登录注册：通过微信授权获取用户身份，使用云函数换取openid，新用户自动建档。
• 测评列表：展示当前可用的量表卡片，包括SCL-90、SAS、SDS等，每张卡片显示预计用时和题目数量。
• 答题页：单选形式逐题作答，支持进度条、上一题/下一题切换，所有题目未答完不能提交。
• 结果页：提交后即时计算总分和各维度得分，用可视化图表展示，并给出常模参考和建议文案。
• 历史记录：查看过往所有测评记录，按时间倒序排列，支持查看每次的详细得分和报告。

管理端功能（Web端或小程序端均可，我放在Web端做）：

• 用户列表：查看注册用户的基础信息、测评次数。
• 测评数据：按量表筛选所有测评记录，支持按异常状态、分数范围过滤。
• 量表管理：新增、编辑、上下架量表，维护题目和选项。

云函数模块：

• login：登录后获取openid。
• getScaleList：获取量表列表。
• getQuestions：获取某个量表的全部题目。
• submitAssessment：提交答案，执行计分逻辑并保存结果。
• getHistory：获取当前用户的历史测评记录。
• getReport：获取某次测评的完整报告。
• adminGetStats（可选）：管理员获取统计数据。

这个清单看起来不算多，但你实际做下来会发现每个模块都有很多细节。尤其是提交测评这个云函数，里面要处理答案校验、计分、常模判定、结果写入，最忙的就是它。

1.3 技术栈选择：为什么我推荐原生开发加云开发

关于技术选型，我知道很多同学会纠结：用uni-app还是原生小程序？用Spring Boot加MySQL还是用云开发？我直接说结论：毕设场景下，原生小程序加云开发是最省心、最不容易翻车的组合。

原生开发的好处是调试方便，微信开发者工具对原生项目的支持最完整，报错信息清晰，社区资料也多。uni-app确实能做到一套代码多端复用，但你大概率只需要发布微信小程序这一端，引入uni-app并没有带来额外收益，反而会在原生组件、第三方插件兼容性上多出很多需要排查的问题。

云开发对比自建后端，最大的优势是不需要考虑服务器运维、HTTPS证书、域名备案这一整条链路。你用Spring Boot写接口确实看起来很"传统扎实"，但后续要解决的问题非常多：服务器买哪家、数据库怎么装、接口怎么部署、域名怎么备案、小程序request域名怎么配置。这些事情任何一个卡住都会让你心态崩溃。云开发开箱即用，云函数天然支持微信鉴权，数据库权限规则可以做到用户级隔离，这些能力正好命中小程序开发的全部痛点。

另外云开发还有一个隐性好处：它天然是"服务端无状态"的架构。你在答辩时说"使用云函数实现业务逻辑，云函数按需执行、自动扩缩容，无需关心服务器资源"，这句话本身就体现了你对现代后端架构的理解，比"我用Tomcat部署了一个Spring Boot项目"听起来更像行业内正在做的事情。

2. 页面结构与交互设计

2.1 页面流转与核心路由

小程序的页面结构我在app.json里维护，大概分四个Tab页面加一组功能页。Tab页包括首页（测评广场）、记录（历史测评）、个人中心、关于我们。功能页包括测评详情、答题页、结果页。

这里有一个特别值得注意的分包问题。微信小程序主包限制是2MB，如果你把SCL-90这种90道题的问卷数据直接写进主包里，很容易超限。我的做法是：主包只放Tab页和公共组件，答题页、结果页、题目数据全部放分包，等用户真正点击"开始测评"时才加载对应分包。这样首屏加载快，也不容易触发包体积告警。

页面路由方面，我用的是常规的wx.navigateTo跳转。有一点要提：答题页这种需要保留状态、防止误触返回的页面，建议在onUnload里判断一下是否已提交，如果没提交弹窗提示用户"测评进行中，退出将不保存结果"。这个小细节做完之后，整个系统的完成度会明显高一个档次。

2.2 测评页交互：单选框与滑动题项的处理

测评页是整个小程序交互最密集的地方，也是很多同学容易做简陋的地方。SCL-90这类量表的选项是"没有、很轻、中等、偏重、严重"这样的五级单选，实现时使用radio-group加radio组件是最直接的方案。但真正要注意的是状态管理和用户体验。

第一，选项状态要持久化。用户答到第50题时切出去回了条微信，回来发现前面选的答案全没了，这种体验会直接让用户放弃测评。我的做法是在data里维护一个answers数组，每次切换选项时更新对应下标的值，同时用wx.setStorageSync做一个本地草稿备份，重新进入页面时先读缓存恢复。

第二，进度反馈要明确。顶部用进度条展示"已答/总题数"，百分比同步更新，这样用户能感知到还要多久完成，而不是漫无目的地往下点。

第三，题号跳转能力。我在页面底部放了一个"答题卡"按钮，点击后弹出一个半屏面板，90道题按5x18网格展示，已答的题号高亮。用户可以从任意位置跳回任意题目修改答案。这个功能在真实测评场景里非常实用，因为用户经常想回去改前面的答案，没有这个功能就只能一道一道往前翻。

代码上，radio-group的bindchange事件会带回当前选中的值，需要注意的是radio组件的value属性要设计成数字类型而不是字符串，方便后面计分直接相加。我当时因为value用了字符串"1"和数字1混着传，导致计分时出现totalScore += optionValue变成了字符串拼接，查了半天才发现这个坑。所以强烈建议所有选项value从一开始就用数字，提交答案时再做一次类型校验。

2.3 自定义导航栏与视觉风格

现在小程序做自定义导航栏是很常见的需求，因为默认导航栏样式太单调，和系统整体设计不搭。但自定义导航栏要处理一个核心问题：顶部状态栏高度和胶囊按钮位置在不同机型上不一样。

我的方案是用wx.getWindowInfo()拿到statusBarHeight，再用wx.getMenuButtonBoundingClientRect()拿到胶囊按钮的位置信息，然后自己算导航栏高度和标题居中位置。这个逻辑我封装成了一个navigation-bar自定义组件，所有页面统一引用。视觉效果上，测评类应用需要让人感到放松，所以我用了浅蓝到白的渐变背景，主色调用偏柔和的青色，而不是传统医疗系统那种大红色块。

字体大小和行间距也要照顾答题体验。测评题目普遍比较长，正文区域我用font-size: 32rpx、line-height: 1.8，避免小字导致阅读疲劳。选项文字至少也要30rpx，点击区域要足够大，防止误触相邻选项——这个交互细节在答辩演示时很加分。

3. 核心功能实现与数据设计

3.1 登录与用户信息获取

登录是这个系统第一个要打通的能力，也是很多新手第一次接触小程序时最容易懵的地方。这里要先搞清楚一个概念：微信登录不等于"用户点击授权头像昵称"。

在小程序里，wx.login()会拿到一个临时code，你把code发给后端（或者云函数），后端调用微信接口换取openid。openid才是用户在你这套系统里的唯一身份标识。之前很多旧教程会教用wx.getUserProfile直接拿用户头像昵称，但微信官方已经调整了能力，现在更推荐使用"头像昵称填写能力"，由用户在界面里主动选择头像和填写昵称，而不建议在登录时强制弹窗索取。

我在项目里做了一个折中方案：用户进入小程序后，先用wx.login静默登录拿到openid，此时可以正常使用测评功能，个人中心显示"微信用户"占位。如果用户想在系统里完善个人资料，可以点编辑按钮，用官方button的open-type="chooseAvatar"选择头像，用input输入昵称。这个流程既符合微信最新规范，也不会因为强制授权把用户挡在门外。

云函数login的代码很简单，核心就是交换openid。因为云函数获取openid是免鉴权的，直接读cloud.getWXContext()就行。

javascript复制// cloudfunctions/login/index.js
const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
const db = cloud.database()

exports.main = async () => {
  const { OPENID } = cloud.getWXContext()
  const users = db.collection('users')
  const existing = await users.where({ openid: OPENID }).count()

  if (existing.total === 0) {
    await users.add({
      data: {
        openid: OPENID,
        nickname: '微信用户',
        avatarUrl: '',
        createdAt: db.serverDate(),
        lastLoginAt: db.serverDate()
      }
    })
  } else {
    await users.where({ openid: OPENID }).update({
      data: { lastLoginAt: db.serverDate() }
    })
  }

  return { openid: OPENID }
}

这里有一个常见问题：很多同学直接把openid返回给前端展示，这是不对的。openid属于敏感信息，前端只需要知道自己"已登录"即可，不需要看到具体值。我在前端登录完成后只保存一个hasLogin标记和用户资料，openid只在云函数内部流转，绝不进入页面数据。

3.2 量表的组织与管理

量表数据我用四个集合来组织，分别管理量表、题目、选项和常模参考，这样设计的好处是量表可配置，改题目不用发版。

• scales：量表基本信息，包括scaleId、名称、描述、题目数量、适用人群、预计用时、上下架状态、排序权重。
• questions：所有量表的题目统一放在这个集合里，通过scaleId关联，每条记录包含questionNo题号、stem题干、dimension所属维度。
• options：选项模板，每条记录包含scaleId、optionLabel（没有/很轻/中等/偏重/严重）、optionValue（1/2/3/4/5）。
• dimensionRef：常模参考，记录每个维度的名称和参考范围，用于结果判定。

在小程序端获取题目时，我用云函数同时查questions和options，把题目和选项拼装成一个嵌套结构返回给前端。注意90道题的题目数据量不小，如果一次性全部返回可能有点慢，但实测在云开发内网环境下也就是几十毫秒的延迟，问题不大。如果以后项目大了，可以考虑按维度分批加载，但毕设阶段不需要这么复杂。

SCL-90的90道题分布在10个维度里，包括躯体化、强迫症状、人际关系敏感、抑郁、焦虑、敌对、恐怖、偏执、精神病性等，另外还有一个"其他"维度。我在录入题目时给每条题目标记了dimension字段，后面计分就靠这个字段做分组聚合。

3.3 计分与常模判定逻辑

计分逻辑说难不难，但很容易算错。SCL-90每一道题都是1到5分，1分代表没有，5分代表严重。算分时有两套指标：

第一套是总分汇总，直接把90道题的选项值全部相加，得到总分。同时统计阳性项目数，即选项值大于等于2的题目数量。阳性项目均分则是阳性项目的得分之和除以阳性项目数。

第二套是因子分（维度得分），把属于同一个维度的题目得分求和，再除以该维度的题目数，得到每个维度的平均分。比如"焦虑"维度有10道题，就把这10道题的得分加起来除以10。

判定标准我在维度表里维护了一套经验参考值，比如总分超过160分，或者阳性项目数超过43项，或者任一因子分大于等于2，就提示"建议关注"。这里我要特别说明一句：系统只能做心理健康状态的筛查参考，不能作为医疗诊断依据。我在结果页的文案里也做了明确提示，引导用户如有需要联系学校心理咨询中心。这个设计不仅是负责任的表现，也是答辩时老师一定会问到的点，提前想好说辞很加分。

计分逻辑放在submitAssessment云函数里，前端只负责收集答案并提交，所有分数计算都在云端完成，避免用户篡改。

javascript复制// 简化的计分逻辑
function calculateScore(answers) {
  let totalScore = 0
  let positiveItems = 0
  const dimensionMap = {}

  for (const item of answers) {
    const value = Number(item.value)
    totalScore += value

    if (!dimensionMap[item.dimension]) {
      dimensionMap[item.dimension] = { sum: 0, count: 0 }
    }
    dimensionMap[item.dimension].sum += value
    dimensionMap[item.dimension].count += 1

    if (value >= 2) positiveItems += 1
  }

  const dimensions = []
  for (const key in dimensionMap) {
    dimensions.push({
      name: key,
      score: Math.round(dimensionMap[key].sum / dimensionMap[key].count * 100) / 100
    })
  }

  return { totalScore, positiveItems, dimensions }
}

还要设一道防重复提交的关卡。我在提交时根据scaleId加用户维度查最近一条记录，如果创建时间和当前时间间隔小于10秒，直接返回"请勿重复提交"。这个小逻辑可以防止前端按钮双击导致的重复数据，数据表里也更干净。

3.4 数据集合设计与权限控制

云开发数据库的权限配置是个容易踩坑的地方。默认情况下，集合只允许创建者（管理员）读写，而小程序前端直接读数据库时用的是用户身份，如果不配权限规则，前端会报权限不足。

我的权限策略是这样的：

• scales、questions、options、dimensionRef属于基础配置数据，对登录用户只读，写操作只在云函数或管理端执行。权限规则设为"所有用户可读，仅管理端可写"。
• users集合用来存用户基础资料，权限规则设为"仅创建者可读写"，但由于openid在云函数里才能拿到，前端直读时也不知道自己是谁，我的所有users操作都走云函数完成，前端不直连这个集合。
• assessment_records集合存测评记录，同样"仅创建者可读写"，并且所有读写都走云函数。

云函数在操作数据库时是管理员权限，不受集合权限规则限制，所以把业务逻辑集中在云函数里还能顺便解决权限问题。这个小技巧值得记住：前端直连数据库只适合读公开配置，涉及用户私有数据的操作一律走云函数。

4. 实操过程：从开发到真机预览

4.1 小程序后台配置

开发前，先到微信公众平台注册一个小程序账号，拿到AppID。个人主体可以注册小程序，不过个人主体的部分能力（比如微信支付）会受限，毕设演示用个人主体完全够。

注册完之后，登录小程序后台，需要在"开发管理-开发设置"里记录AppID和AppSecret。AppSecret是敏感信息，只在云函数里通过环境变量引用，不要写进前端代码，也不要把AppSecret提交到Git仓库。

如果你的项目像我当时一样遇到了"改了AppID但开发者工具里还是老的小程序ID"这个混乱问题，多半是因为开发者工具缓存了旧的登录态。解决办法是：在开发者工具右上角"详情-基本信息"里确认AppID，切换账号后重新编译，如果还不行就清理缓存并重启工具。这个坑表面上看起来是玄学，实际上就是缓存和登录态不同步导致的。

4.2 云开发环境初始化

在开发者工具里点击"云开发"按钮，开通云开发环境。这里会要求你填环境名称，我建议用prod和dev这样清晰的命名，不要用默认生成的乱码。环境ID后面会在云函数和前端代码里反复用到，最好起一个一眼能记住的名字。

初始化前端SDK时，在app.js的onLaunch里加入：

javascript复制wx.cloud.init({
  env: 'your-env-id',
  traceUser: true
})

traceUser开启后，云开发控制台可以按用户维度查看调用记录，排查问题时非常有用。

接下来逐个创建云函数。在开发者工具中右键cloudfunctions目录，选择"新建云函数"，工具会自动生成一个index.js模板。你只要把业务逻辑写进去，然后右键云函数文件夹选择"上传并部署：云端安装依赖"就行。这里有个经验：云函数里用到的第三方库（比如一些算法库）需要先在本地的package.json里声明，然后上传时选"云端安装依赖"，而不是"所有文件"，这样能避免把本地node_modules传上去导致体积过大。

4.3 从体验版到正式发布

开发完成后，在开发者工具右上角点"上传"，填写版本号和备注，然后到小程序后台"版本管理"里找到这个开发版本。点"生成体验版二维码"后，你手机扫码就能在真机上体验。

这里我遇到过一个问题：生成体验版二维码后找半天找不到入口。实际上入口在"管理-版本管理-开发版本"区域，版本号右侧有个二维码小图标，点击才会弹出体验版二维码。热度词里排前面的"体验版二维码在哪"大概率问的就是这个。不熟悉后台布局的话很容易忽略。

从体验版到正式发布，还需要在小程序后台提交审核。审核的时候要注意：如果你的测评结果页有"建议就医"、"心理疾病"这类敏感字眼，审核可能会要求你提供相关资质证明。我的做法是把所有医疗诊断类表述改成"建议与学校心理中心沟通"、"结果仅供参考"这类中性文案，同时在类目选择上选择了"教育-教育信息服务"而不是"医疗"，这样审核通过率会高很多。

上线之后如果小程序代码有更新，还需要走一遍"提交审核-发布"流程。但体验版和开发版可以随时更新，不受审核限制，所以平时调试用体验版就够了，正式版本可以等所有功能稳定后再提交。

5. 常见问题与排查技巧

5.1 真机测试网络错误：net::ERR_CONNECTION_RESET

这是我在真机测试时踩过的第一个大坑。在开发者工具上一切正常，一上真机就报failed: net::ERR_CONNECTION_RESET，页面白屏或请求失败。

排查思路是：先在开发者工具右上角"详情-本地设置"里勾选"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"，看看网页是否恢复正常。如果勾选后正常，说明问题出在合法域名配置或者HTTPS证书上。如果你用的是云开发，理论上不存在域名配置问题，此时检查一下当前环境是否选对了——开发者工具默认连接的是dev环境，如果你的数据都在prod环境，真机上读不到数据也会表现类似症状。

另外一个常见原因是基础库版本太低。在开发者工具"详情-本地设置"里可以切换调试基础库，建议选一个较新的稳定版本，再在真机上调一次。云开发的API在旧基础库上兼容性并不好，遇到奇怪的网络错误先升基础库准没错。

5.2 用户登录信息获取失败

"小程序获取登录后的微信用户失败"这个问题，在很多人刚接触小程序时会频繁碰到。原因绝大多数是把旧版的wx.getUserProfile用在了新版基础库上，或者用了wx.getUserInfo但没在button的open-type="getUserInfo"里触发。

微信现在对用户信息获取的管控越来越严，直接在onLoad里调用wx.getUserInfo会返回失败。正确做法是：用户主动点击一个按钮，通过open-type="chooseAvatar"选择头像，通过input输入昵称。至于登录态，用wx.login换取code再交给后端，这个是不会有弹窗和授权问题的。

如果你的云函数里一直获取不到OPENID，检查一下云函数是否真的部署成功，以及前端调用是否真的走wx.cloud.callFunction。我见过有人把云函数参数写成了name: 'login'但实际云函数文件夹名是loginV1，导致一直提示函数不存在。这类问题最好在云开发控制台的"云函数"页面看日志，报错信息比前端要详细得多。

5.3 分包、上传与AppID问题

关于分包，有两个常见错误：一是subpackages的根路径配置错误，导致加载分包时报"分包加载失败"；二是分包内的页面跳转路径没有写成/subpackages/xxx/index这种完整路径。第一次做分包时我在这上面耗了一晚上，最后发现只是路径少写了一个层级。

上传失败的问题，最常见的三种情况：AppID填写错误、队列中已有上传任务、工具登录态过期。前两种好排查，第三种只要重新登录一下微信开发者工具就行。另外注意每个小程序每天有上传次数限制，频繁调试时可能会提示"今日上传次数已用完"，这种情况只能等第二天或换个账号。

"在HBuilderX中运行时小程序id还是原来的"这个问题，本质上是HBuilderX和微信开发者工具之间的AppID配置脱节。HBuilderX项目里AppID配置位于manifest.json的微信小程序配置项中，你需要确认改的是这里，而不是只在HBuilderX的某个构建配置里改。改完以后，建议清掉微信开发者工具的编译缓存，然后在HBuilderX里选择"重新运行到微信开发者工具"，不要只点刷新。

5.4 其他值得记录的坑

• maximum setlocal recursion level reached这个报错看起来像是小程序代码问题，实际上是你本机的CMD环境变量递归层级过多导致的，和项目代码没有直接关系。解决办法是清理系统环境变量中过长或循环引用的Path，然后重新打开命令行终端。
• content-type无法置空通常出现在上传文件时。微信小程序某些版本会强制给请求设置Content-Type，如果你需要上传二进制数据并希望header的Content-Type为空，可以试一下wx.uploadFile，上传文件场景下Content-Type由框架自动处理，不需要也不应该手动置空。
• 小程序A跳小程序B之前，需要在小程序后台的"设置-第三方设置-关联小程序"里完成关联，并且在前端代码里调用wx.navigateToMiniProgram时传入正确的appId和path。只写了代码但没做后台关联，跳转一定会失败。
• 很多同学想在自己的服务器上部署小程序后端，其实完全可以。前端小程序通过wx.request请求你自己的HTTPS接口，和云函数语法略有不同。但走这条路的同学要提前解决域名备案、HTTPS证书、服务器安全性三个问题，预算不足的话不太建议作为毕设首选。

6. 毕业设计答辩与演示准备

6.1 演示脚本怎么设计

答辩演示比大多数人想象中容易翻车，最大的原因是现场网络不稳定。所以我强烈建议你把演示流程设计成"先本地后云端"：打开开发者工具用模拟器展示核心页面流转，遇到网络波动也不用慌。

我给自己准备的演示脚本是这样的：先用手机扫体验版二维码展示真实场景，然后切回开发者工具演示代码结构。演示时重点走一条顺畅的业务链路：登录进入首页 -> 选择SCL-90 -> 快速做完10道题 -> 提交 -> 展示结果页的得分和雷达图 -> 进入历史记录查看刚才的记录。这条链路大概3分钟，刚好覆盖了系统的所有核心功能。

剩下的时间留给技术讲解。我会打开云开发控制台，现场展示数据库中的assessment_records集合，看一条记录的结构，说明每个字段的含义。再打开一个云函数的日志，展示submitAssessment的调用记录和耗时。这些"后台视角"的展示能直观体现你的系统是真实可运行的，不是纯前端画页面。

6.2 技术亮点怎么讲

答辩时讲技术亮点，不需要讲得多么高深，但要体现出你是经过思考做出来的。根据我的经验，下面几组亮点比较容易被评委认可：

第一，架构设计上的无服务器化。云函数按需执行、自动扩缩容、免运维。这句话展开来就是：你不需要关心服务器资源规划，云平台会为每个请求分配资源，处理完自动释放。这符合当前行业从服务器架构向Serverless架构演进的趋势。

第二，数据权限的安全设计。用户私有数据全部通过云函数访问，前端不直接操作敏感集合。云数据库的权限规则保证了用户A无法读取用户B的测评记录。你在答辩时可以现场用另一个微信号测试，展示两个账号的数据相互隔离。

第三，测评系统的业务可配置性。量表、题目、选项、常模参考全部分表存储，运营人员可以通过后台修改量表内容，不需要改动一行代码。这展示了你的数据建模能力。

第四，前端体验细节。答题中途退出有保存提示、答题卡可以跳题修改、自定义导航栏适配不同机型、结果页可视化展示。这些细节不是技术难点，但能体现你对用户体验的重视。

6.3 可扩展方向

毕设做完以后，如果你还有精力或者想为以后的项目积累素材，以下几个方向都是很自然的扩展。

订阅消息提醒可以在用户完成测评后，通过微信订阅消息推送一条"报告已生成"的通知，引导用户回到小程序查看。实现上要调用requestSubscribeMessage接口，在自建后端或云函数里调用订阅消息发送API。这个功能不算复杂，但能让系统看起来更完整。

预警通知机制：当测评结果显示"建议关注"时，系统可以自动通知心理中心老师。学生角度看到的是正常结果页，但老师后台会多出一条待处理预警记录。这个功能如果做出来，整个系统的核心价值会更明确，答辩时的业务阐述也会更有底气。

AI辅助解读：用大模型接口对测评结果做自然语言解读，比如根据不同的分数区间生成个性化建议文案。这块可以做得简单一点，比如预设模板加规则引擎，也可以调用现有的NLP能力。我个人觉得这是一个能让项目在答辩时"眼前一亮"的亮点，但别把它作为必做项，先把基础功能打磨扎实。

数据统计大屏：管理端加一个可视化统计页面，展示各维度得分分布、各年级参与率、历史趋势等。用图表库（比如ECharts）就能实现，技术难度不高，但视觉冲击力很强。

我在整个开发过程中最深的感受是：毕业设计不是要把功能做到大而全，而是要在有限的工程复杂度内，把一条核心业务链路做深做透。从登录到测评再到结果展示，每一步都经得起追问，数据表设计能说清楚为什么这么建，云函数逻辑能讲明白异常情况怎么处理，这样就算代码量不算很多，也依然是一份高质量的作品。按照上面这条路走下来，你的系统不仅在功能上是完整的，在技术表达和答辩呈现上也都有了足够的支撑。