企业官网建设流程全解析

校园里做心理健康测评，最怕的就是一套系统做出来没人用，或者用了一次就吃灰。大学生心理健康测评这类应用，表面看是“填问卷、出分数”，实际上是“普查—测评—预警—干预—随访”的完整闭环，前端体验、数据安全、预警时效每一项都牵一发动全身。我最近完成的这套基于微信小程序的测评平台，正是围绕这个闭环展开，技术选型上用了 UniApp 多端框架，一套代码同时覆盖微信小程序、H5 和 App，目前已经在学校心理中心平稳运行。这篇内容会把整个项目的设计思路、核心模块的落地方式、我踩过的坑和一些直接能抄的代码片段整理出来，给准备做类似校园应用的朋友作参考。

如果你是在校学生、心理中心的信息化负责老师，或者想找一个真实业务场景练手的小程序开发者，这篇文章都值得看完。下面我就从整体设计开始，一步步拆解这套平台的实现逻辑。

1. 项目定位与整体设计思路

1.1 需求从来不是“做一个测评问卷”那么简单

我刚接到这个需求时，对方描述很简单：“做个微信小程序，让学生能在手机上做心理测评，老师能看结果。”但真把需求拆开后，事情远没有那么轻松。

首先得明确用户角色。平台上有三类人：

• 学生：通过微信授权登录，绑定学号姓名，完成量表测评，查看自己的历史记录和报告；
• 心理中心老师：查看测评完成情况、预警名单、跟进干预记录；
• 系统管理员：负责量表管理、权限分配、数据导出。

其次是业务流程。大学生心理健康测评的核心场景是新生入学心理普查，全校几千人同时在几天内完成测评，结束后心理中心会筛出需要重点关注的学生。这就决定了系统必须具备三个能力：高并发下的稳定作答、基于量表规则的分级预警、以及后续老师跟进处理的状态流转。

还有一个容易被忽视的需求——隐私边界。心理测评数据比普通成绩数据敏感得多，学生本质上并不希望辅导员能看到自己每一道题的作答明细。所以权限设计上，辅导员只能看到“是否需要关注”的结论，心理中心老师才能看到完整报告，这层逻辑必须一开始就定下来。

在技术选型上，项目最终确定的方案是：微信小程序作为学生端载体，UniApp 作为前端开发框架。微信小程序的好处不用多说，学生无需下载 App，微信扫一扫或者搜一下就能用，用完即走，触达率非常高。而 UniApp 的价值在于，它让这个项目保持了“以后想扩展就扩展”的可能性——万一哪天需要做 App 端或者 H5 版，同一套 Vue 代码可以直接编译过去。

1.2 为什么选 UniApp 而不是原生小程序

开发微信小程序原生方案也能做，那为什么还要套一层 UniApp？这是我在项目中经常被问到的第一个问题。

这里没有绝对的对错，但如果你的团队本身熟悉 Vue，UniApp 显然是更平滑的选择。我在这个项目里选择 UniApp 还有三个实际理由：

第一，项目不只需要小程序。心理中心希望后续把教师端做成 H5 管理后台，学生端则保留在微信里，如果写原生小程序，H5 就要另起炉灶。用 UniApp，管理后台也能复有一部分组件和工具函数。

第二，UniApp 的条件编译帮了大忙。微信小程序里有些 API（比如wx.setVisualEffectOnCapture防截屏接口）在 App 端不存在，用// #ifdef MP-WEIXIN包一层就能优雅处理，不用担心编译到其他端时报错。

第三，组件生态成熟。心理测评要处理大量表单、步骤条、进度条、图表，uni-ui 里现成的组件可以直接改样式用，省去从零手写组件的时间。

不过也要说句公道话，UniApp 并非没有代价，它封装了一层，意味着遇到底层问题时排查链路变长，有些微信小程序独有的新特性，要等 UniApp 官方同步支持。但对一个校园项目来说，这种代价完全可控。

2. 核心功能模块拆解与实现要点

2.1 登录体系与多角色权限设计

小程序端登录我采用了一套比较稳妥的“静默登录 + 学号绑定”模式。

首次打开小程序，前端调用uni.login获取临时 code，发给后端换取 openid，建立微信身份。但这还不够——学校需要知道这个微信背后是谁。所以我在首次登录后会强制跳转“学号 + 姓名 + 身份证后几位”的绑定页，对接学校统一身份认证接口后完成实名关联。

这个方案有几个好处：

• 学生第二次进入时可以实现静默登录，体验顺畅；
• 后台可以直接按学院、专业、班级维度统计完成率；
• 即使学生更换微信号重新绑定，历史测评数据也能通过学号关联回来。

权限这块，前端做的是“按钮级控制”，后端做的是“接口级控制”。老师端登录后，UniApp 根据角色字段渲染不同的 TabBar 和页面入口。前端控制只是为了体验更好，真正的安全边界在后端——学生身份的 token 不允许访问老师端接口，这个防护逻辑必须放在服务端做。

关于心理测评的知情同意，我在小程序第一个页面放了《知情同意书》全文，只有点击“同意并开始”按钮后才可以进入测评列表。这个设计既是伦理要求，也避免了后续纠纷。

2.2 测评引擎：量表配置、计分规则与防作弊机制

平台内置了三个核心量表：SDS 抑郁自评量表、SAS 焦虑自评量表、UPI 大学生人格问卷，同时预留了 SCL-90 症状自评量表的配置位。

这里重点说一下计分逻辑，这是最容易做错的地方。以 SDS 为例，量表共 20 个条目，按 1～4 级评分。其中有 10 个条目是反向计分题（第 2、5、6、11、12、14、16、17、18、20 题），反向题需要按“5 - 选项值”转换后再累加。所有条目分数相加得到粗分，标准分 = 粗分 × 1.25 后取整数部分。

// 前端只做展示和基础校验，最终分数以后端计算为准 function calcSDS(rawScores) { const reverseItems = [2, 5, 6, 11, 12, 14, 16, 17, 18, 20] let total = 0 rawScores.forEach((score, index) => { total += reverseItems.includes(index + 1) ? (5 - score) : score }) const stdScore = Math.floor(total * 1.25) return stdScore }

按临床参考标准，SDS 标准分在 53～62 为轻度，63～72 为中度，72 以上为重度。需要特别说明的是，这个结果只能作为日常状态评估参考，不能作为临床诊断依据。我在测评报告页底部固定展示了一行免责声明：“本结果不能替代专业医疗诊断，如有需要请前往学校心理中心或专业医疗机构”。这个细节非常关键，产品可以帮人发现问题，但不能越界去“下诊断”。

防作弊机制同样是测评模块的重头戏。坦白说，大学生做心理测评时最容易出现的情况是快速乱答。我做了三道防线：

1. 最短作答时间：每个量表按题目数量设定最短用时，比如 20 题的 SDS 最短 60 秒，若提前提交，后端直接打上“疑似无效”标记；
2. 切屏控制：答题过程中一旦切换到其他应用或小程序，onHide 事件触发计时，累计超过 3 次或者单次超过 30 秒，强制弹窗要求重新确认作答意愿，后端记录可疑日志；
3. 后端校验：前端提交的所有作答明细都有作答时长、修改次数等元数据，后端对这些数据做二次校验，异常答卷自动进入“待审核”队列。

2.3 预警规则与干预闭环

测评分值本身没有意义，真正有价值的是根据分值触发的后续动作。我在项目里设计了三级预警规则：

• 黄色预警：SDS 标准分达到 63～72，或 SAS 达到 60～69，系统提示“建议关注”；
• 橙色预警：连续两次测评 SDS 标准分均超过 63，系统提示“建议约谈”；
• 红色预警：单次 SDS 标准分超过 72，或答卷中涉及“自杀念头”条目得分异常，系统提示“需尽快干预”。

预警触发后，前端学生端会显示暖心提示语，并引导预约心理中心咨询；管理端则会把该生信息（脱敏后的学号、姓名、所属学院）推送到心理中心老师的待办列表。老师完成约谈后，需要在系统中记录干预结果，由此形成“普查—测评—预警—干预—随访”的业务闭环。

干预闭环里 UI 设计有一个很微妙的点：学生端绝对不能出现“你属于重度抑郁风险”这种红字标题，这会加剧心理压力，文案必须保持温和、建设性，多用“你最近可能比较累，建议找人聊聊”这类表达。

2.4 数据报表与可视化

管理端的数据看板是整个平台给心理中心最直观的“价值证明”。看板展示了测评完成率、各学院参与趋势、量表分数分布、预警人数统计等内容。

图表这块我在 UniApp 里对比过 ECharts 和 uCharts。简单结论是：

• uCharts是专门往小程序方向打磨的，渲染性能好，包体积小，普通柱状图、折线图足够用；
• ECharts图表类型更丰富，但体积大，而且在微信小程序里跑 canvas 会有性能瓶颈，需要结合 renderjs 方式优化。

如果你在 Vue3 + UniApp 项目里想用 ECharts，需要这样处理：把 echarts 核心通过 renderjs 挂到视图层，逻辑层只负责传数据，这样能避免 canvas 在小程序里频繁 setData 导致的卡顿和白屏问题。图表导出图片时，用 canvasToTempFilePath 生成临时文件再保存，注意 iOS Safari 下 canvas 队列导出偶发白图，导出前要做一个延时等待。

3. 实操过程与关键代码实现

3.1 请求封装、拦截器与多域名切换

项目里所有请求都走一个封装好的request.js。我基于uni.request包了 Promise，并用uni.addInterceptor拦截器统一处理 token 注入、状态码异常、登录过期重定向。直接看代码：

// utils/request.js const BASE_URL = getBaseURL() function getBaseURL() { // #ifdef H5 // H5 端部署多个域名时，按当前 host 动态切换后端 if (location.hostname.includes('dev')) return 'https://dev-api.psy.com' if (location.hostname.includes('school-a')) return 'https://a-api.psy.com' return 'https://api.psy.com' // #endif // #ifndef H5 return 'https://api.psy.com' // #endif } export function request(options) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + options.url, method: options.method || 'GET', data: options.data || {}, header: { 'Content-Type': 'application/json', Authorization: uni.getStorageSync('token') || '', ...options.header }, success: (res) => { if (res.statusCode === 401) { uni.removeStorageSync('token') uni.reLaunch({ url: '/pages/login/index' }) return } if (res.statusCode >= 200 && res.statusCode < 300) { resolve(res.data) } else { reject(res) } }, fail: reject }) }) }

热搜里提到的“H5 指向 2 个域名”在实践中很常见，比如同一套代码部署在两个学校的服务器上，后端地址不同。上述按location.hostname动态匹配的方案就能直接解决问题。但小程序端不同，微信公众平台后台只能配置合法的 request 合法域名，不支持运行时动态域名，所以小程序端的 BASE_URL 必须是固定的线上地址，开发调试时才在微信开发者工具里勾选“不校验合法域名”。

3.2 自定义导航栏与胶囊按钮适配

测评页面需要沉浸式作答体验，默认导航栏太丑，我改成了自定义导航栏。但这就会遇到一个经典问题：微信小程序右上角胶囊按钮的位置在不同机型上不一样。

通过uni.getMenuButtonBoundingClientRect()拿到胶囊按钮的坐标，再结合状态栏高度动态计算导航栏的高度：

// 自定义导航栏高度计算 const systemInfo = uni.getSystemInfoSync() const menuButton = uni.getMenuButtonBoundingClientRect() const statusBarHeight = systemInfo.statusBarHeight || 20 const navBarHeight = (menuButton.top - statusBarHeight) * 2 + menuButton.height

有了这两个值，页面自定义 header 的高度就可以精确适配，不会出现胶囊按钮遮挡标题的问题。腰果按钮底部那片安全区也要处理，页面底部需要加padding-bottom: env(safe-area-inset-bottom)，避免 iPhone 底部横条遮挡“上一题/下一题”按钮。

3.3 缓存设计：给本地缓存设置过期时间

uni.setStorageSync本身没有过期时间概念，学生端的测评报告、已读消息等数据如果不设过期时间，会一直堆在本地。我封装了一个带过期时间的缓存方法：

const setCache = (key, value, expireHours = 24) => { const data = { value, expire: Date.now() + expireHours * 3600 * 1000 } uni.setStorageSync(key, data) } const getCache = (key) => { const data = uni.getStorageSync(key) if (!data || data.expire < Date.now()) { uni.removeStorageSync(key) return null } return data.value }

测评进度这种需要长时间保留的数据，我单独设置 72 小时过期，保证学生断线退出后重新进入还能续答。注意一点：心理健康相关的明细数据不要整体缓存到本地，测评页退出时只保留“当前题号”和“已完成答案”，不做整份量表的本地明文存储，降低数据泄露风险。

3.4 manifest 配置、自定义分享与防截屏

UniApp 项目的manifest.json是配置大门，小程序 appid 在这里填，H5 的路由模式也在这里选。我的配置要点如下：

• 小程序模块配置：只需要勾选 Location（用于线下咨询室地图引导）、Share 等基础模块；
• H5 配置：路由模式选 hash，避免部署到学校服务器后刷新 404；
• App 端：打包时配置图标和启动图，同时开启安全区适配。

自定义分享是校园应用的刚需，学生把测评活动分享给同学，基本靠微信好友。在页面中写：

onShareAppMessage() { return { title: 'XX大学心理健康普查', path: `/pages/assess/index?code=${this.shareCode}`, imageUrl: 'https://api.psy.com/share-card.png' } }

这里有个安全细节：分享链接里不能拼用户的长期 token，我后端生成一个 10 分钟有效期的短 code，通过接口换取身份，避免分享链接泄露隐私。

防截屏和防录屏对心理测评场景来说不是噱头，而是为了降低学生在截图传播方面的顾虑。微信小程序里可以调用wx.setVisualEffectOnCapture开启截屏保护，UniApp 中用条件编译包住：

// #ifdef MP-WEIXIN wx.setVisualEffectOnCapture({ visualEffect: 'hidden' }) // #endif

这行代码放在测评页onLoad里，让涉及敏感题目的页面在系统截屏时自动隐藏。

3.5 虚拟支付的扩展避坑

平台目前是学校心理中心免费为学生提供服务，不涉及支付。但如果你后续要扩展付费咨询预约、情绪课程等模块，一定要知道微信小程序的红色禁区：iOS 端小程序不支持虚拟支付，不管是用微信支付还是支付宝都会被拒，只能走苹果内购或者引导用户到 H5 完成支付。Android 端则可以正常拉起微信支付。这是我在另一个知识付费小程序项目里踩过的坑，适用到这里也成立，提前做好平台差异判断，别等到提审被拒再返工。

4. 常见问题与避坑实录

4.1 生命周期与页面栈的坑

UniApp 页面生命周期有onLoad、onShow、onReady、onHide、onUnload，但实际开发中它们的行为有差别，尤其在测评场景下。

我遇到最多的一个坑：测评中切后台再回来，onShow会重新触发，此时答题计时如果放在onLoad里启动就会出问题——切后台时onHide执行，但定时器没有清除，导致后台计时继续。解决方式是在onHide里记录时间戳并清除定时器，onShow时根据时间差累加切屏时长，达到阈值触发异常标记。

还有一个页面栈的坑：uni.navigateTo最多只能打开 10 层页面，测评流程如果设计成“列表页-答题页-结果页-详情页”一直往下跳，第 11 次调用会直接静默失败。解决方式是测评页用uni.redirectTo代替navigateTo，不让页面栈无限累积。

4.2 兼容性的真实情况

UniApp 口号是“一套代码多端运行”，但实际真机测试你才会发现，每个端都有自己的小脾气。我在这个项目里碰到过下面这些兼容问题：

4.3 性能优化与包体积控制

新生测评的时段几乎是一个明确的高并发窗口，全校几千名学生同时在线，不能指望每道题都实时请求后端。前端层面的优化手段如下：

• 主包分包：测评答题页和结果页拆到分包，保证主包体积在 2M 以内，提高小程序审核通过率和加载速度；
• 预加载：做完登录后立刻预请求学生信息和量表列表，等用户进问卷页时数据已经在内存里，不用白屏等待；
• 虚拟列表：管理端的学生列表数据量很大，DOM 节点超过 500 个时小程序明显卡顿，用分页加载 + 触底自动追加的方式限制单屏节点数。

另外，ECharts 图表按需引入模块非常关键，不要整库 import，只引入折线图和柱状图模块，包体积能减少 60% 以上。

4.4 安全与隐私底线：心理数据的合规实践

这一部分在技术社区里很少被认真讲，但恰恰是心理测评平台最重要的地方。

首先是数据加密传输。全部接口走 HTTPS，测评提交接口额外加签名和时间戳，防止接口被恶意重放调用。

其次是最小化存储原则。学生端不缓存完整量表明细；服务端对测评报告设置访问权限，心理中心老师可以看，辅导员只能看到预警级别，普通管理员无法导出明细数据。

第三是用户控制权。小程序的用户协议和隐私政策指引里，必须写明数据的收集范围、存储期限、使用目的，以及学生申请删除数据的渠道。做这套平台时我还专门跟学校信息中心确认了数据安全责任归属，心理数据的存储设备、备份策略、访问日志都有明确要求。

最后是心理伦理红线。所有测评报告页面固定展示三行内容：结果仅供参考、不能替代医疗诊断、出现心理危机时如何第一时间求助。这句话看着简单，却是产品责任的一部分。出了任何问题，产品逻辑上必须能自证清白。

5. 上线前后的运营实践与我的体会

5.1 第一次高峰前的准备

新生心理普查那几天是我们压力最大的时刻。上线前一周我做了三件事：

第一，错峰分批推送。不是让所有学生同时收到通知，而是按学院分了三个批次，每批间隔半天，避免瞬间流量打爆后端。

第二，后端接口压测。测评提交接口设置了 QPS 阈值，我用压测脚本模拟了 2000 人同时提交的场景，发现数据库连接池满了，于是加了连接池上限和读写分离，才把接口压下来。

第三，准备应急预案。如果小程序在线人数过多，立即开启“答题暂存”模式，学生每答完一页自动暂存，避免回答到第 50 题时网络一断全部丢失。我们在高峰期确实触发了几次，好在预案生效，没有掉链子。

5.2 这个项目教会我的几件事

整套系统跑下来，我最深的体会是：技术上的坑都可以用代码解决，最难的是把产品定位想清楚。心理测评平台的核心不是“测得多准”，而是“测完以后怎么办”。如果预警名单生成之后老师没有跟进，那平台做得再漂亮也只是个问卷工具。

另外一点，关于 UniApp 和微信小程序的关系，我的态度是：不要神化框架，也不要低估框架。UniApp 确实帮我省掉了多端维护的成本，但在真机上该调试还得调试，该看微信开发者工具的控制台还得看，框架只是缩短了开发路程，没替你把工程质量背起来。

如果你也想做这个方向，我的建议是先跑通最核心的“测评 + 预警”闭环，再逐步加功能。量表规则、权限体系、隐私合规这三件事，越早定清楚，后面返工越少。希望这篇拆解能帮你少走几步弯路。