uniapp+SSM志愿者活动报名小程序：从设计到部署全流程解析

1. 志愿者活动报名，真不是“做个报名页面”那么简单

这两年社区和高校的志愿者活动越来越多，我接过好几个类似的需求：组织者拿着一堆Excel表格统计报名信息，手动核对名额、手动通知、手动记时长。活动一多，这套流程基本就崩了——漏报、重复报名、临时取消、签到对不上号，全是问题。

所以当我拿到“uniapp+SSM志愿者活动报名服务小程序”这个项目的时候，第一反应就是：这不只是写个报名页面的事，而是要解决活动组织全流程的管理问题。从前端小程序到后端服务，从活动发布、名额控制、报名审核到签到统计，每一环都要串起来。

这篇文章我会把这个项目的完整设计与开发思路拆开讲，包含技术选型理由、数据库设计、SSM后端接口实现、uniapp前端关键页面、以及我实测中踩过的坑和解决方案。不管是正在做毕业设计，还是想给组织团体做一套真实可用的报名系统，这篇文章都能提供直接参考。

先给个结论：uniapp负责一套代码多端运行，SSM负责稳定可靠的后端业务逻辑，两者通过RESTful API通信。这就是整个项目最核心的骨架。

2. 技术选型：uniapp和SSM为什么是这套组合

2.1 前端选uniapp的真实理由

要用“小程序”这个词，但实际开发时如果你只盯着微信小程序写原生代码，后面大概率会后悔。理由很简单：等你做完微信小程序版本，甲方或老师说“能不能顺便出个App”的时候，原生小程序代码基本等于重写。

uniapp的优势在于它基于Vue语法，一套代码可以编译到微信小程序、支付宝小程序、H5、iOS和Android。我实际项目里，同一个报名系统的小程序端和H5管理端共享了大部分代码，省了很多时间。

再说几个uniapp在小程序场景里实用的点：

• 自带uni.request封装，API风格统一，不用在小程序原生wx.request和H5的axios之间来回切。
• 页面路由、生命周期、组件化方式都贴近Vue，上手门槛低。
• 有成熟的条件编译机制，#ifdef MP-WEIXIN这种写法可以针对不同平台写差异化代码。
• 插件市场里有现成的UI组件库（比如uView、ColorUI），做表单和管理页面效率极高。

2.2 后端为什么还在用SSM

很多人会觉得SSM“老”，但这个项目选它恰恰是因为它的特点符合需求。

SSM是Spring + SpringMVC + MyBatis的组合。Spring负责对象管理和事务控制，SpringMVC负责接收前端请求并路由到对应处理方法，MyBatis负责数据库操作。这套组合的核心价值在于：结构清晰，职责分明，资料极多，问题好查。

对于志愿者报名这种业务逻辑不算极端复杂、但数据关系很清晰的项目，SSM非常合适。而且如果这是毕业设计或课程项目，SSM几乎是评审老师最熟悉的框架，答辩时更容易讲清楚每个请求是怎么被处理的。

我后来也想过用Spring Boot重写，确实配置更少、启动更快，但从项目教学和演示角度来看，SSM的XML配置反而能把Spring的IoC和AOP原理讲明白，这是框架自动配置做不到的。

2.3 整体架构：前后端分离的思路

这个项目采用前后端分离架构，前端uniapp通过HTTP请求调用后端接口，数据格式统一使用JSON。

用户（微信小程序端） → uniapp应用 → HTTP请求 → SpringMVC Controller → Service层 → MyBatis Mapper → MySQL数据库

分离的好处是：小程序端只管页面展示和用户交互，后端只管业务逻辑和数据持久化。后续如果要做管理后台网页、App版本，后端接口完全可以复用。

3. 数据库设计：活动、志愿者、报名记录怎么串起来

3.1 核心数据表梳理

数据表是整个系统的基础，我设计了5张核心表：

需要注意的几点：

openid是志愿者的唯一标识。用户首次通过微信授权登录时，后端通过code换区openid并存入volunteer表。后续所有报名、查询都基于这个openid关联用户。

activity表里的status字段我设计为三种状态：0-未开始报名、1-报名中、2-活动结束。这个状态决定了前端是否展示报名按钮。

signup_record表的status字段同样重要：0-待审核、1-已通过、2-已拒绝、3-已取消。报名不等于成功，很多活动是需要管理员审核的，这一点在业务上很关键。

3.2 并发场景下的名额控制

这是整个项目最容易出问题的点。如果活动名额只剩1个，但同时有5个人提交报名，怎么保证不超报？

我的做法是给signup_record表加唯一约束(activity_id, volunteer_id)，防止同一个人重复报名；同时在Service层用事务控制更新名额：

@Transactional public synchronized boolean signUp(int activityId, int volunteerId) { // 1. 查询活动信息 Activity activity = activityMapper.selectById(activityId); if (activity.getStatus() != 1) { return false; // 不在报名中状态 } // 2. 检查是否已满 if (activity.getCurrentPeople() >= activity.getMaxPeople()) { return false; } // 3. 检查用户是否已报名 int count = signupRecordMapper.checkExist(activityId, volunteerId); if (count > 0) { return false; } // 4. 插入报名记录 SignupRecord record = new SignupRecord(); record.setActivityId(activityId); record.setVolunteerId(volunteerId); record.setStatus(0); signupRecordMapper.insert(record); // 5. 更新活动当前报名人数 activityMapper.increaseCurrentPeople(activityId); return true; }

虽然用synchronized在单机部署下足够，但如果想更稳，可以用数据库的行锁SELECT ... FOR UPDATE，或者用Redis做分布式锁。考虑到这个项目的量级，我用了事务加唯一约束，实测够用。

4. SSM后端：从项目搭建到核心接口实现

4.1 项目结构规划

后端项目按经典三层架构分包：

src/main/java ├── controller // 接收请求，返回JSON ├── service // 业务逻辑层 ├── mapper // MyBatis数据访问层 ├── entity // 实体类 └── common // 通用工具类、返回结果封装

Maven依赖方面重点说几个：mybatis-spring负责整合MyBatis和Spring，jackson-databind负责JSON序列化，fastjson我用来处理微信登录返回的数据。数据库连接池用druid，它自带的监控页面排查问题非常方便。

4.2 返回结果统一封装

前后端分离必须统一返回格式。我封装了一个Result类：

public class Result<T> { private Integer code; // 200成功，404失败，500异常 private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.setCode(code); result.setMessage(message); return result; } }

所有Controller的返回值都是Result类型，前端判断code是否为200决定业务是否成功。这个封装看起来简单，但能省掉大量前后端联调时“字段对不上”的沟通成本。

4.3 微信登录接口实现

小程序端首先要解决的是用户身份识别。我用的是微信小程序的wx.login获取code，后端拿着code调用微信接口换取openid：

@PostMapping("/login") public Result login(@RequestBody Map<String, String> params) { String code = params.get("code"); // 调用微信接口 String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + code + "&grant_type=authorization_code"; String result = httpUtil.get(url); JSONObject json = JSON.parseObject(result); String openid = json.getString("openid"); // 如果用户不存在，则新增 Volunteer volunteer = volunteerService.findByOpenid(openid); if (volunteer == null) { volunteer = new Volunteer(); volunteer.setOpenid(openid); volunteer.setNickname("微信用户"); volunteerService.insert(volunteer); } // 生成自定义登录态（可以用UUID或JWT） String token = UUID.randomUUID().toString().replace("-", ""); // 将token存到Redis或内存中，后续请求通过token识别用户 return Result.success(token); }

注意这里我不会把openid直接返回给前端，而是用token作为登录凭证。你没看错，openid相当于用户在微信体系下的身份证号，泄露出去有安全隐患。这也是实际开发中容易忽略的问题。

4.4 活动接口：列表、详情、分页

活动列表接口要支持分页和按分类筛选：

@GetMapping("/activity/list") public Result getActivityList(@RequestParam(defaultValue = "1") int page, @RequestParam(defaultValue = "10") int pageSize, @RequestParam(required = false) Integer typeId) { PageHelper.startPage(page, pageSize); List<Activity> list = activityService.findAll(typeId); PageInfo<Activity> pageInfo = new PageInfo<>(list); return Result.success(pageInfo); }

这里用到了PageHelper分页插件，它会自动拦截MyBatis的SQL并拼接LIMIT，不用手动写分页逻辑，非常省事。前端拿到的数据里包含total、pages、list等字段，直接在uniapp的uView组件里渲染即可。

活动详情接口同样直接查表返回，但我额外做了两个字段的组装：isSignUp（当前用户是否已报名）和signedUpCount（当前已报名人数），这样前端活动详情页不用再额外请求一次报名状态。

4.5 报名和签到接口的事务处理

报名的Service层代码上面已经给了核心逻辑，这里补充一个容易被忽视的点：签到接口要和报名状态联动。

@PostMapping("/signin") public Result signIn(@RequestBody Map<String, String> params) { Integer activityId = Integer.valueOf(params.get("activityId")); Integer volunteerId = Integer.valueOf(params.get("volunteerId")); // 验证是否已报名且审核通过 SignupRecord record = signupRecordMapper.selectByActivityAndVolunteer(activityId, volunteerId); if (record == null || record.getStatus() != 1) { return Result.error(404, "未报名或审核未通过，无法签到"); } // 判断是否已签到 if (record.getCheckinTime() != null) { return Result.error(500, "请勿重复签到"); } record.setCheckinTime(new Date()); signupRecordMapper.updateById(record); return Result.success(); }

签到这个动作在真实场景里有很多方式，扫码签到、定位签到、管理员手动签到。我倾向于在项目里提供两种：管理员在小程序管理端手动标记签到，以及志愿者在活动现场用小程序扫码签到。推荐把定位签到作为扩展功能，调用uni.getLocation判断志愿者是否在活动地点一定范围内。

5. uniapp前端：页面搭建和报名流程的实现细节

5.1 页面结构和登录流程

uniapp项目的pages.json是路由配置文件，我规划了这些页面：

登录流程是我在这个项目里最强调的部分。小程序默认冷启动后静默登录，也就是在App.vue的onLaunch里调用uni.login拿code，然后请求后端/login接口获取token，存到uni.setStorageSync。用户感知不到登录过程，体验最好。

// App.vue onLaunch() { this.checkLogin(); }, methods: { async checkLogin() { const token = uni.getStorageSync('token'); if (token) { // 每次启动可以校验token是否过期 return; } uni.login({ provider: 'weixin', success: (loginRes) => { console.log('code:', loginRes.code); uni.request({ url: `${baseUrl}/login`, method: 'POST', data: { code: loginRes.code }, success: (res) => { if (res.data.code === 200) { uni.setStorageSync('token', res.data.data); } } }); } }); } }

5.2 活动列表页和下拉刷新

活动列表页是用户的第一屏，我使用了uView的u-waterfall效果，不过更常见的是v-for渲染卡片列表。每个卡片展示活动封面、标题、时间、地点、剩余名额。

下拉刷新是必须的，因为用户进入页面后活动状态可能已经变化：

<template> <view> <view class="activity-list" v-for="item in activityList" :key="item.id" @click="goDetail(item.id)"> <view class="card"> <image :src="item.coverUrl" mode="aspectFill"></image> <view class="info"> <view class="title">{{ item.title }}</view> <view class="time">{{ item.startTime }}</view> <view class="location">{{ item.location }}</view> <view class="status-tag" :class="item.status === 1 ? 'active' : 'end'"> {{ item.status === 1 ? '报名中' : '已结束' }} </view> </view> </view> </view> </view> </template>

活动列表的下拉刷新和触底加载，我用的是onPullDownRefresh和onReachBottom这两个生命周期。注意要在pages.json里设置"enablePullDownRefresh": true。

5.3 活动详情页和报名流程

活动详情页需要请求两个数据：活动信息和当前用户的报名状态。我建议把详情和状态合并成一个接口返回，避免前端多次请求。

点击报名按钮后，弹出一个报名表单面板，里面填姓名、手机号、以及自定义的报名备注。这里要注意手机号正则校验不能省：

const checkPhone = (phone) => { const reg = /^1[3-9]\d{9}$/; return reg.test(phone); };

提交报名后前端调用后端接口，根据返回的code值判断结果。这里我会做一次防重复点击：按钮提交后立即置灰，避免用户手滑连点两次导致报名两次。

5.4 获取路由参数的正确姿势

热词里提到“uniapp中获取路由的参数”，我在开发中也老是踩这个坑。在小程序端，页面跳转传参不是用Vue Router的this.$route.query，而是要用onLoad生命周期：

// 从列表页跳转详情页 goDetail(id) { uni.navigateTo({ url: `/pages/activity/detail?id=${id}` }); } // 详情页接收参数 onLoad(options) { this.activityId = options.id; this.getActivityDetail(); }

如果你需要在页面跳转时传递对象，记得用encodeURIComponent(JSON.stringify(obj))序列化，接收时再JSON.parse(decodeURIComponent(options.xxx))。直接JSON.stringify传参会因为特殊字符导致解析失败。

5.5 我的报名列表：状态分类展示

个人中心的报名记录需要支持“全部/待审核/已通过/已拒绝”几个分类切换。实现上是给后端接口传status参数：

getMySignups(status) { uni.request({ url: `${baseUrl}/signup/myList`, data: { volunteerId: this.volunteerId, status }, success: (res) => { this.signupList = res.data.data.list; } }); }

这里提醒一下：volunteerId不要从小程序端传，应该由后端根据token解析出用户身份。如果你直接把volunteerId作为接口参数，那么任何人都可以查别人的报名记录了。正确的做法是后端拦截器从token中获取用户ID。

// 伪代码：从token解析用户 String token = request.getHeader("token"); Integer volunteerId = tokenService.getVolunteerId(token);

这个问题在毕业设计答辩时是评委重点关注的安全漏洞之一。

6. 管理员端：活动发布、审核、签到全流程

6.1 管理员身份判定

不是说做一个小程序，用户就全是志愿者。系统内有管理员角色，负责发布活动、审核报名、管理签到。管理员端我并没有单独做一个管理App，而是通过普通小程序里的“管理入口”加上权限控制来实现。

具体做法：用户登录后，后端返回用户角色标识（0-普通志愿者、1-管理员）。小程序端根据角色动态显示或隐藏管理相关的入口。

// 个人中心 if (this.role === 1) { this.menuList.push({ name: '活动管理', url: '/pages/admin/activityManage' }); this.menuList.push({ name: '报名审核', url: '/pages/admin/auditList' }); }

注意这只是一个显示控制，真正的权限校验必须由后端完成。我在后端加了一个简单的拦截器，判断请求的Controller路径和用户角色是否匹配，防止有人绕过前端直接请求管理接口。

6.2 活动发布的状态机设计

管理员发布活动的流程是：填写基本信息 → 设置报名时间 → 设置名额 → 提交审核（可选） → 发布。

活动状态的流转是整个项目里最容易出错的部分。我用了一个简单的时间判断：

public Activity fillActivityStatus(Activity activity) { Date now = new Date(); if (activity.getSignupStartTime().after(now)) { activity.setStatus(0); // 未开始 } else if (now.after(activity.getSignupStartTime()) && now.before(activity.getSignupEndTime())) { activity.setStatus(1); // 报名中 } else { activity.setStatus(2); // 已结束 } return activity; }

把这个方法放在返回前端之前调用，保证前端拿到的状态永远是实时的，不用手动更新数据库里的status字段。

6.3 报名审核列表

管理员进入“报名审核”页面后，看到的是某个活动的所有报名记录。审核操作就是简单更新signup_record表的status字段为1或2。

审核这里有个体验细节：审核通过后，如果用户在审核前已经取消了报名，那就不能再次通过。所以审核前要校验当前记录的状态还是待审核：

@PostMapping("/audit") public Result audit(@RequestParam Integer recordId, @RequestParam Integer auditResult) { SignupRecord record = signupRecordMapper.selectById(recordId); if (record.getStatus() != 0) { return Result.error(500, "该记录不在待审核状态"); } record.setStatus(auditResult); // 1通过，2拒绝 signupRecordMapper.updateById(record); return Result.success(); }

6.4 签到管理

签到有两种常见方式：

一是管理员在活动开始后，从报名审核列表进入签到，点击“标记签到”。这种方式适合线下由工作人员统一核对身份。

二是志愿者扫码自助签到，管理员在活动开始时生成活动专属二维码，前端调用uni.scanCode解析出活动ID，然后请求后端签到接口。

扫码签到的坑是：如果活动地点信号不好，扫完码请求后端超时，用户会以为签到成功了。我的处理方式是要么等请求成功后再提示“签到成功”，要么在请求失败时允许重新扫码，不记录失败状态。

7. 部署上线与实测：从本地到真机的完整链路

7.1 后端部署要点

后端SSM项目最终打成WAR包部署到Tomcat，或者打成JAR包用java -jar运行。我实际采用的方式是Tomcat 8.5 + JDK 1.8 + MySQL 5.7 + Maven构建，这是在服务器上兼容性最稳的组合。

服务器需要开的端口就是Tomcat的8080端口（或你用Nginx代理后的80端口），数据库3306端口只允许本机访问，外部连不上。

有一件事容易忘：服务器上的MySQL安装完必须改utf8mb4编码，否则小程序端提交的表情符号（emoji）会因为utf8只能存3字节而报错“Incorrect string value”。

7.2 微信小程序发布配置

从uniapp编译到微信小程序，需要在manifest.json里配置微信小程序的AppID。然后在微信开发者工具里打开编译生成的dist/dev/mp-weixin目录，上传代码后在微信公众平台提交审核。

有几个细节需要注意：

• 域名必须是HTTPS。微信小程序要求所有请求的API域名必须在公众平台配置为request合法域名，且必须是备案过的HTTPS域名。本地开发可以勾选“不校验合法域名”，但上线前必须解决。
• 用户隐私协议。微信现在强制要求小程序在收集用户信息前弹窗告知，代码里需要在app.json声明__usePrivacyCheck__，并处理隐私授权回调。之前热词里就提到“uniapp ios app当用户不同意隐私政策及用户协议时退出app的代码”，这在小程序端更是不能忽视。
• App审核更严格。如果你想用uniapp打包成App上架安卓应用市场，需要在manifest.json里配置完整的图标、启动页、权限说明，很多市场还要求提供软件著作权证书。这一点提前准备能省很多事。

7.3 实测环境与性能表现

我测试时用的是：微信开发者工具模拟器 + 微信开发者工具真机预览 + iPhone手机扫码测试。整体接口响应速度在100~300毫秒之间，活动列表加载50条数据时页面渲染流畅。

后端Tomcat连接数我开的默认200，对于这个项目完全够用。数据库连接池配的Druid最大连接数30，也没有出现连接不够的情况。压测时用JMeter模拟了200个并发报名请求，名额控制正常，没有出现超报。

8. 实战踩坑：那些文档里不会写清楚的细节

8.1 软键盘遮挡输入框

热词里提到“uniapp 微信小程序 手机软键盘会遮挡住查询内容”，这我确实遇过。在小程序里，页面底部输入内容时，软键盘弹起会遮挡住输入框。

网上普遍的方案是设置adjust-position="true"，但实测在某些安卓机型上没用。我最终的解决方案是给底部输入框外层包一层view，用CSS的fixed定位，配合小程序的onKeyboardHeightChange动态调整底部偏移：

onKeyboardHeightChange(res) { this.keyboardHeight = res.height; }

<view class="input-area" :style="{ bottom: keyboardHeight + 'px' }"> <input v-model="remark" placeholder="请输入备注" /> <button @click="submit">提交</button> </view>

8.2 onShareAppMessage被全局方法覆盖

热词里“uniapp onshareappmessage 被全局方法覆盖”，这也是我亲自踩过的。在App.vue里如果定义了onShareAppMessage，某个页面里没有重新定义时，分享就会用到全局配置，但有时候页面里定义了却发现不生效。

原因是：在App.vue中定义的onShareAppMessage并不是全局分享配置，而页面中的onShareAppMessage才是。如果全局方法里写了返回值，它可能会覆盖页面生命周期里的方法。

我的处理方式是：不在App.vue写分享逻辑，而是在每个需要分享的页面单独写onShareAppMessage，或者在main.js里用Vue.mixin给需要分享的页面添加统一方法：

Vue.mixin({ onShareAppMessage() { return { title: '志愿者活动中心', path: '/pages/index/index' }; } });

8.3 小程序路由跳转的限制

uni.navigateTo只能跳转非TabBar页面，且小程序原生限制页面栈最多10层。如果你在活动详情页跳报名页，报名页提交成功后又想跳回详情页，直接用navigateTo会导致栈溢出。

我推荐两种方案：

• 提交成功后用uni.redirectTo代替navigateTo，当前报名页会被替换成目标页。
• 或者提交成功后uni.navigateBack回到详情页，详情页在onShow里刷新报名状态。

submitSignup() { uni.request({ url: `${baseUrl}/signup`, method: 'POST', data: { activityId: this.activityId, remark: this.remark, realName: this.realName, phone: this.phone }, success: (res) => { if (res.data.code === 200) { uni.showToast({ title: '报名成功', icon: 'success' }); setTimeout(() => { uni.navigateBack(); // 回到详情页 }, 1500); } } }); }

8.4 uniapp打包安卓的离线配置

热词里“uniapp怎么打包”，这里展开说一下。打包App有两种方式：云打包和离线打包。云打包直接在HBuilderX里操作，不需要本机安装Android Studio，但对免费用户有次数限制且排队时间不短。离线打包则需要下载Android Studio、配置对应的SDK，自由度更高但上手成本也大。

如果你只是做一个毕业设计或内部系统，我推荐直接用云打包。需要注意的地方是manifest.json里的基础配置：

• 应用名称、图标、启动图必须配好。
• 模块权限勾选：定位、相机、获取网络状态等，按需勾选，选多了会导致审核变严格。
• 离线打包时一定要确保原生工程里dcloud_properties.xml和AndroidManifest.xml配置一致，否则可能出现白屏或签名不对的问题。

8.5 排查问题的主要工具

项目联调阶段，除了看后端控制台日志，我最常用的是：

• 微信开发者工具的Network面板：查看请求是否成功、返回数据是否符合预期。
• Charles抓包工具：排查真机请求时要用。不过因为现在很多抓包工具需要给手机装证书，Android 7.0之后默认不信任用户证书，所以如果你遇到请求报SSL错误，检查一下是不是证书信任问题。
• 后端日志：SSM项目里我用的是Logback，配置了控制台和文件双输出。排查问题时直接看logs目录下的日志文件，用grep定位异常比盯着控制台翻滚动效率高得多。

9. 从SSM项目到系统思维：报名之外还能扩展什么

项目做完之后，我觉得最值得分享的不是代码本身，而是从“报名功能”延伸到“活动运营”的系统化思考。如果你需要把它做得更完整，下面这些方向都是很有价值的扩展：

9.1 消息通知

现在报名审核结果只能用户自己刷新查看，体验不够好。可以用小程序订阅消息功能，在用户报名成功后申请订阅“审核结果通知”的授权，管理员审核通过后通过后端调用微信接口发送订阅消息（需要先获取用户的formId或一次性订阅消息token）。这个功能要特别注意微信订阅消息的模板ID和用户授权次数的限制。

9.2 志愿时长统计

报名审核通过 + 签到成功后，系统可以自动记录志愿服务时长。需要在signup_record表加个duration字段，活动结束时由管理员统一录入，或者在签到和签退之间自动计算。个人中心可以展示累计时长、活动次数、服务星级，这些都是志愿者评优的硬指标。

9.3 数据可视化

热词里提到“uniapp 使用echarts”，其实小程序端用echarts需要引入echarts-for-weixin组件，且体积不小，需要考虑分包加载。更实用的做法是把数据统计接口放在后端，前端用uCharts或F2绘制简单的柱状图、饼图，展示每个月的活动数量、参与人数、热门活动类型。

9.4 活动评价反馈

活动结束后，让志愿者对活动进行打分和留言。这不仅能提升平台活跃度，也为活动组织者提供了改进依据。数据表可以增加activity_comment表，关联活动ID和志愿者ID，设置唯一约束防止重复评价。

这些扩展方向不用一次性全做完，但架构上要提前留好位置。比如signup_record表加duration字段不影响现有逻辑，但如果一开始把表设计死了，后面改动就要动很多层代码。

写在最后的建议

经过完整开发，我的体会是：uniapp+SSM的确是这个项目的最优解之一。uniapp让我不用纠结多端适配，SSM让我能清楚地掌控每一层逻辑，数据库设计则是整个项目的灵魂——表关系理清了，业务代码写起来又快又稳。

如果你正在做类似项目，我的建议是：

1. 先画表结构，再写接口，最后碰前端。很多人上来就写接口，结果数据库字段不够用，后面返工成本极高。
2. 报名、审核、签到这三个状态字段一定要设计好。它们贯穿整个项目，一旦设计混乱，前端判断和后端逻辑都会变得一团糟。
3. 安全问题不要留到答辩前才补。token鉴权、接口权限、数据脱敏，这些一开始就要有，否则后面补特别费劲。
4. 把可能用到的扩展功能留好接口。不用现在全部实现，但数据库设计时要考虑消息通知、时长统计、评价反馈等潜在需求。

我实际跑下来，这套系统从开发到上线大概用了三周时间。前端页面是10个左右，后端接口是20个左右，核心表结构就上面那几张。如果你有更复杂的需求，比如多组织入驻、活动费用缴纳、志愿者培训考核，在这个基础上往上加就行，整体架构不用动。

希望这篇文章能帮你少走一些弯路。如果有同学正在纠结“uniapp怎么做登录”“SSM怎么返回JSON”“审核流程怎么写”，可以直接对照着本章的代码去改。祝各位开发顺利，把项目从“能用”做到“好用”。