简介这是一份基于微信小程序开发的在线活动报名系统完整源码面向小程序初学者、前端开发者及需要快速搭建活动报名场景的运营人员。项目实现活动展示与分类、报名表单填写、微信支付集成、报名状态追踪、消息推送等核心模块并配有后台管理功能可覆盖活动发布、用户报名、数据查看与处理的全流程。压缩包共74个文件以png图标资源、js逻辑代码、wxss样式、wxml页面结构和json配置文件为主整体仅81KB目录层次清晰便于直接导入微信开发者工具运行或按需二次定制。已有898人学习下载适合通过阅读pages、utils、services等模块理解小程序生命周期、WXML/WXSS语法及微信开放接口的典型用法。开发者可从中获得一套可运行的前后端交互示例同时参考支付、消息推送及个人中心等模块设计快速迁移到自己的实际项目中。1. 微信小程序在线活动报名系统为什么表单提交不等于报名成功做微信小程序-在线活动报名系统本质是把「发布活动 → 用户浏览 → 填写报名 → 名额管理 → 名单导出」这条链路完整搬进小程序里。我见过不少开发者和活动运营把这件事想简单了一个活动列表、一个表单页、一个提交按钮看上去跑通了结果活动真正开放报名那天重复提交、库存超卖、手机号拿不到、用户收不到确认通知随便一个都能让活动方在开场前夜手忙脚乱。下面会把报名系统的核心链路拆开讲清楚页面骨架怎么做、微信登录态怎么接、提交接口怎么设计、有哪些坑必须提前避开。适合正准备自己开发报名小程序或者接手这类项目的开发者阅读。2. 报名页面的最小闭环从活动列表到提交按钮的骨架2.1 先定技术选型原生框架是报名系统的最短路径做这个项目的第一步不是写页面而是定框架。常见做法有两种微信原生小程序框架或者 Uniapp 这类跨端方案。就报名系统而言我更推荐原生框架尤其是只做小程序端、不带 App 的场景。理由有三点。第一微信登录、手机号授权、订阅消息这些报名系统的关键能力原生框架的封装链路最短官方文档对应最直接出问题时能少绕一层。第二原生框架在微信开发者工具里的调试体验最稳定报错信息能直接定位到代码文件。第三报名系统本身的业务逻辑不算复杂原生的开发效率完全够用。Uniapp 的优势在多端复用但打包到微信小程序时经常遇到 source size 超过 2MB 上限的问题还要处理自定义组件和原生 API 的差异对「只做小程序」的报名业务来说属于额外成本。页面结构上一个最小可用的报名小程序只需要三个页面pages/activities/list活动列表展示可报名的活动pages/activities/detail活动详情展示时间、地点、剩余名额pages/signup/form报名表单收集姓名、手机号和备注在app.json里注册页面{ pages: [ pages/activities/list, pages/activities/detail, pages/signup/form ], window: { navigationBarTitleText: 活动报名, navigationBarBackgroundColor: #ffffff } }pages数组里的第一项是启动页这里把活动列表作为首页。navigationBarTitleText决定顶部导航的标题会直接影响用户第一眼看到的品牌信息建议改成活动方的名称不要用默认的「微信小程序」。2.2 活动列表与 wx.request 渲染合法域名是第一个拦路虎活动列表页的数据来源是后端接口。小程序端用wx.request发起请求这跟浏览器里的fetch类似但有一个硬性约束请求的域名必须在小程序后台配置到 request 合法域名列表里否则真机上直接请求失败。开发者工具里可以临时勾选「不校验合法域名」来调试但这只是本地开关上线前必须把域名配好而且要求 HTTPS。列表页的 JS 逻辑如下Page({ data: { activities: [], loading: true }, onLoad() { this.fetchActivities() }, fetchActivities() { wx.request({ url: https://api.example.com/api/activities, method: GET, success: (res) { if (res.statusCode 200 res.data.code 0) { this.setData({ activities: res.data.data.list, loading: false }) } }, fail: () { wx.showToast({ title: 活动列表加载失败, icon: none }) this.setData({ loading: false }) } }) } })这里有几个参数值得说明。url必须是线上可访问的 HTTPS 接口method默认是GET列表查询用 GET 没问题。success回调里我习惯先判断statusCode再做业务码code的判断——HTTP 200 只代表请求通了不代表业务成功。fail回调处理的是网络层异常比如断网、域名未配置、证书过期这些情况要单独给用户提示不能静默失败。对应的 WXML 用wx:for循环渲染活动卡片每一张卡片展示标题、时间和剩余名额点击后跳转详情页view classactivity-list view wx:for{{activities}} wx:keyid classactivity-card view classactivity-title{{item.title}}/view view classactivity-time{{item.start_time}} - {{item.end_time}}/view view classactivity-remain剩余名额{{item.remaining}}/view button bindtapgoDetail>const PHONE_RE /^1[3-9]\d{9}$/ Page({ data: { form: { name: , phone: , remark: } }, onSubmit() { const { form } this.data if (!form.name || form.name.trim().length 2) { wx.showToast({ title: 请填写真实姓名, icon: none }) return } if (!PHONE_RE.test(form.phone)) { wx.showToast({ title: 手机号格式不正确, icon: none }) return } // 校验通过进入提交流程 this.submitSignup(form) } })/^1[3-9]\d{9}$/这个正则覆盖了目前国内绝大部分手机号段。需要说明的是正则只能校验格式不能校验号码是否真的在用所以服务端提交后还要做一次同样的校验并在必要时接入短信验证码。trim()处理的是用户输入前后空格的情况这类细节在表单场景里很常见——用户从通讯录复制号码时经常会带一个空格。前端校验只是体验优化真正的安全边界在后端。这一点在第四章的接口设计里会重点展开。3. 微信登录与手机号授权让报名数据具备实名可用性3.1 wx.login 换 openid先搞清楚谁在报名报名系统最容易被忽略的是「身份」问题。活动方要的是名单但如果名单里只有姓名和手机号没有任何微信身份标识一旦用户说「我没报过名」或者「我报错了想取消」你很难定位到具体记录。所以第一步要先接微信登录。wx.login是微信小程序的身份入口它拿到的code是一个临时凭证需要发给后端由后端去微信接口换openidwx.login({ success: async (res) { if (!res.code) { wx.showToast({ title: 登录失败请重试, icon: none }) return } const loginRes await new Promise((resolve) { wx.request({ url: https://api.example.com/api/auth/login, method: POST, data: { code: res.code }, success: resolve }) }) if (loginRes.data.code 0) { wx.setStorageSync(token, loginRes.data.data.token) } } })后端拿到code后用jscode2session接口换取openidconst axios require(axios) const APPID 你的小程序AppID const APPSECRET 你的小程序AppSecret const { code } req.body const url https://api.weixin.qq.com/sns/jscode2session const { data } await axios.get(url, { params: { appid: APPID, secret: APPSECRET, js_code: code, grant_type: authorization_code } }) const openid data.openid这段代码有两个关键点。第一APPID和APPSECRET在小程序后台的「开发管理 - 开发设置」里获取APPSECRET只能保存在服务端绝不能写进小程序代码里。第二openid是用户在当前小程序下的唯一标识换到另一个小程序会变所以它只能用来识别「谁在这个小程序里操作」不能跨小程序使用。后端拿到openid后查用户表存在则复用记录并签发自定义token不存在则创建新用户。token的有效期我一般设 2 小时过期后前端再调wx.login走一次静默登录用户无感知。3.2 手机号快速验证组件报名数据能不能用的关键姓名可以随便填手机号却必须是真实的否则活动方联系不上用户。微信提供了手机号快速验证组件用户点击一次授权微信直接返回手机号不需要手动输入也省掉了短信验证码的成本。组件的用法是一个带特殊open-type的按钮button open-typegetPhoneNumber bindgetphonenumberonGetPhoneNumber 使用微信手机号快速验证 /button对应的 JS 处理onGetPhoneNumber(e) { if (e.detail.errMsg ! getPhoneNumber:ok) { wx.showToast({ title: 需要授权手机号才能报名, icon: none }) return } // e.detail.code 是动态令牌传给后端换取真实手机号 wx.request({ url: https://api.example.com/api/signup/phone, method: POST, data: { code: e.detail.code }, success: (res) { const phone res.data.data.phoneNumber this.setData({ form.phone: phone }) } }) }这里要特别注意新版手机号验证组件返回的不是加密数据而是一个code动态令牌。后端需要用这个code调用微信的getuserphonenumber接口换取真实的手机号接口地址是POST https://api.weixin.qq.com/wxa/business/getuserphonenumber?access_tokenACCESS_TOKEN请求体只需要一个字段{ code: 用户端传过来的动态令牌 }。响应里的phone_info.phoneNumber就是完整手机号。这个方案省掉短信成本但对真机测试要求很高。开发者工具里点击手机号授权按钮返回的是模拟数据不能代表真实链路。所以涉及手机号授权的功能必须在真机上完整测一遍。测试时还要覆盖「用户拒绝授权」的场景——拒绝后要能给出友好提示最好保留手动输入手机号的入口做兜底。3.3 报名记录落库openid、手机号与唯一索引怎么配合登录态和手机号都接好后要设计数据表。报名系统的核心是两张表一张存活动一张存报名记录CREATE TABLE activities ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(128) NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, total_quota INT DEFAULT 0, remaining INT DEFAULT 0, status TINYINT DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE signups ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, activity_id INT NOT NULL, name VARCHAR(64) NOT NULL, phone VARCHAR(20) NOT NULL, status TINYINT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_activity (user_id, activity_id), UNIQUE KEY uk_activity_phone (activity_id, phone) );signups表里存了user_id和activity_id两个外键但没有用外键约束只建了普通索引。这样做的原因是外键约束在高并发写入时开销大而报名系统的并发峰值往往集中在活动开放报名的那几秒去掉外键约束能减少锁竞争。uk_user_activity唯一索引保证同一个用户对同一个活动只能报一次名这是常规做法。uk_activity_phone是额外加的一道锁用来防「一个人换个微信号再报一次」——同一个活动下相同手机号只允许出现一条报名记录。这两个唯一索引是数据库层面的兜底比应用层if判断可靠得多。status字段默认 0后面在第四章的状态机里解释。4. 报名提交与库存扣减接口设计、原子操作与状态机4.1 报名提交接口字段、返回与异常约定报名接口是整个系统的核心接口字段设计要一次到位避免后期返工。常见的报名提交接口是POST /api/signup请求体如下{ activityId: 10, name: 张三, phone: 13800001111, remark: 带一个朋友 }activityId对应活动表主键name是报名人姓名phone是手机号remark选填。注意这三个字段必须全部由服务端重新校验不能信任前端传过来的任何值。返回体统一用一个结构{ code: 0, message: ok, data: { signupId: 123 } }code是业务状态码。我习惯把业务码和 HTTP 状态码分开HTTP 200 不代表报名成功一切以code为准。报名接口可能出现的业务码如下code含义前端提示0报名成功成功跳转结果页4001参数错误请补充必填项4002活动不存在活动已下线4003活动未开始或已结束当前不在报名时间4004名额已满手慢了下次早点4005重复报名你已报过该活动接口层把业务码定清楚前端处理逻辑就简单了showToast根据code映射提示语即可。如果后端还返回了data.signupId前端可以把它带上作为报名记录的凭证。4.2 库存扣减用原子操作先查后写一定会超卖报名系统最经典的坑是库存超卖。活动只有 50 个名额结果 52 个人报名成功。原因几乎都是同一个先查剩余名额再判断是否能报名最后更新库存。错误写法是这样的SELECT remaining FROM activities WHERE id 10; -- 假设查出来 remaining 1此时判断remaining 0然后执行更新。问题在于两个请求可能同时查出remaining 1都判定可以报名然后都执行扣减最终名额变成 -1。正确的做法是单条 SQL 完成「判断 扣减」UPDATE activities SET remaining remaining - 1 WHERE id ? AND remaining 0;这行 SQL 的巧妙之处在于WHERE remaining 0如果剩余名额是 0更新不生效affectedRows为 0。应用层只需要判断affectedRowsaffectedRows 1扣减成功继续插入报名记录affectedRows 0名额已满返回4004扣减和插入报名记录必须放在同一个事务里START TRANSACTION; UPDATE activities SET remaining remaining - 1 WHERE id ? AND remaining 0; -- 如果 affectedRows 0这里直接 ROLLBACK INSERT INTO signups (user_id, activity_id, name, phone, status) VALUES (?, ?, ?, ?, 0); COMMIT;为什么必须用事务因为扣减库存和插入报名记录是两步操作如果先扣库存、插入失败名额就凭空消失了反过来先插入、扣减失败用户会看到报名成功但实际没占上名额。事务保证这两步要么都成功要么都失败。如果插入时报唯一索引冲突重复报名事务回滚后已经扣掉的名额会自动恢复不需要额外补偿逻辑。4.3 报名状态机取消报名必须归还名额signups表里的status字段需要一个明确的状态机。常见的报名状态状态值含义说明0待确认刚提交等待活动方审核1已确认审核通过正式占一个名额2已拒绝活动方驳回3已取消用户或活动方取消4已签到活动当天完成签到状态流转有几个约束待确认可以流转到已确认或已拒绝已确认可以流转到已取消已取消和已拒绝是终态不能回退已签到只有在活动结束后由活动方在后台操作。取消报名时要记得归还名额UPDATE signups SET status 3 WHERE id ? AND status IN (0, 1); UPDATE activities SET remaining remaining 1 WHERE id ?;这两条语句同样要放在事务里顺序上先更新报名状态、再归还名额。归还名额时要保证只有status IN (0, 1)的记录才能取消已签到的记录不能取消否则会出现活动都结束了名额还在变的情况。5. 报名系统的 5 个高频避坑点真机、并发与时间校验5.1 用户收不到报名确认通知订阅消息的「一次性」授权陷阱现象用户在报名页填完表单点了提交报名记录也插进去了但用户一直收不到确认通知活动方后台确认了也没用。原因微信小程序的订阅消息是「一次性订阅」——用户每次同意授权只能收到一条消息。如果代码里把wx.requestSubscribeMessage放在onLoad里调用或者在用户还没有交互时触发微信会直接拒绝授权。而且模板 ID 配错、模板内容审核未通过也会静默失败前端不报错。解决把订阅消息的请求放到报名按钮的bindtap回调里用户在点击按钮这一瞬间发起订阅请求这是微信允许的交互时机onSubmit() { wx.requestSubscribeMessage({ tmplIds: [模板ID], success: (res) { // 无论用户是否同意都继续提交报名 this.submitSignup() }, fail: () { this.submitSignup() } }) }要点是订阅消息的成功与否不能阻断报名流程用户拒收通知也要允许报名否则活动方会流失大量潜在报名者。服务端在报名状态变更时从待确认到已确认调用发送接口用openid定位接收人。5.2 开发者工具能拿手机号真机上拿不到现象手机号快速验证组件在微信开发者工具里点一下就能返回手机号但真机预览时点了授权要么没反应要么弹了授权框却拿不到数据。原因开发者工具里手机号组件返回的是模拟数据不经过微信真实链路。真机上受微信版本、基础库版本、用户是否已授权等条件影响任何一个环节不满足都会失败。解决涉及getPhoneNumber的功能必须用真机预览测试不要依赖开发者工具模拟器。onGetPhoneNumber回调里要同时判断errMsg和errCodeonGetPhoneNumber(e) { if (e.detail.errMsg ! getPhoneNumber:ok) { // 给用户一个可回退的入口 this.setData({ showManualPhoneInput: true }) return } // 正常处理动态令牌 }活动报名是低频场景用户授权失败后最友好的做法是显示一个手动填写手机号的输入框配合短信验证码兜底既保证号码真实又不让用户卡死在授权页。5.3 抢报名瞬间库存变负数现象活动 10:00 开放报名10:00:02 后台就显示剩余名额变成 -2报名人数超过了活动名额。原因库存扣减用了「先查后写」的非原子操作或者把判断逻辑写在了应用层两个请求同时读到相同的剩余名额都通过了if判断。解决用第四章的原子扣减 SQLUPDATE activities SET remaining remaining - 1 WHERE id ? AND remaining 0。数据库行锁会挡住并发更新同一时刻只有一个请求能扣减成功。如果活动报名人数达到几千人、并发极高可以在 Redis 里提前加载名额用DECR原子操作扣减再异步同步到数据库。但大多数场地类活动几十到几百个名额数据库原子扣减已经足够不需要引入 Redis 增加运维复杂度。5.4 同一手机号被不同微信号反复报名占名额现象用户先报上名又换一个微信号提交了一次报名两个名额都被同一个真人占用。原因微信的openid是按微信号维度唯一的防不住同一个人换号。如果报名表只对user_id activity_id建唯一索引数据库层面拦不住这种重复。解决在signups表上增加(activity_id, phone)唯一索引。这是我在 3.3 节建表时就强调的。有了这道约束数据库会在插入时直接拒绝同一手机号在同一活动的第二条记录应用层捕获唯一索引冲突返回4005重复报名。要注意这个约束的前提是活动规则为「一人一票」如果活动允许代报名一个人给三个人报名这个方案就不适用了需要改成业务层判断、增加代办人与被代办人手机号维度。5.5 活动结束后还能提交报名现象前端报名按钮在结束时间后已经置灰但有用户反馈仍然报名成功。原因前端只是把按钮置灰、加了倒计时这是「体验层」控制用户完全可以通过其他手段绕过前端直接构造请求调用后端接口。后端没有校验活动时间窗口只校验了参数和名额。解决服务端在报名接口里强制校验当前时间和活动时间的关系if (now activity.start_time || now activity.end_time) { return { code: 4003, message: 当前不在报名时间 } } if (activity.status ! 1) { return { code: 4002, message: 活动已下线 } }这里的时间要以服务端为准不能信任客户端传的时间。用户改自己手机时间没有任何意义因为判断发生的服务端。这是一个典型的「前端控制体验、后端控制安全」的边界问题报名系统里凡是涉及状态判断的逻辑服务端都要做一遍完整校验。6. 让报名系统能收尾验证清单、日志回溯与核销习惯6.1 上线前按这张清单跑一遍报名系统的功能不复杂但边界条件多。我整理的验证清单每次上线前会完整跑一遍验证项操作预期结果页面跳转列表页 → 详情页 → 报名页活动 ID 正确透传手机号授权真机首次点击授权 / 拒绝授权成功返回手机号拒绝出现手动输入兜底重复报名同一微信号提交第二次返回 4005名额不减少同号换号同一手机号配不同微信号报名返回 4005只允许一条记录并发抢报两台设备同时提交最后一个名额只有一人成功库存不为负时间校验手动把活动改为已结束再调接口返回 4003拒绝报名这张清单覆盖了第五章提到的全部坑点。每次改完代码我都会至少跑一遍「重复报名」和「并发抢报」两项因为这两项一旦出错就是活动事故级别的故障。6.2 用 requestId 串联一次报名的完整链路活动方反馈「用户报不上名」时最怕的是什么都查不到。我习惯在服务端入口中间件给每个请求生成一个requestIdapp.use((req, res, next) { req.requestId ${Date.now()}-${Math.random().toString(36).slice(2, 8)} res.setHeader(X-Request-Id, req.requestId) next() })报名提交时把requestId和user_id、activity_id一起存入signups表后续排查时输入手机号或openid就能反查requestId再到日志系统里定位请求从入口到数据库每一步的执行情况。这个习惯帮我省掉了无数次「用户报不上名但是不知道在哪一步失败」的排查时间。我自己经手的报名类小程序每次上线前都会把清单完整过一遍尤其是库存扣减和重复提交这两个坑一旦踩了就是现场事故。后来我养成了一个固定习惯任何一次改动哪怕只是改了一个提示文案也要先跑「提交一次、再提交一次」这个最基本的回归用例。报名系统代码量不大但边界条件比想象中多服务端多做一层校验前端多留一个兜底入口胜过上线后熬夜补锅。希望帮到你。本文还有配套的精品资源点击获取
