简介一套完整的微信小程序在线活动报名系统源码适合微信小程序开发者、前端学习者及需要快速搭建活动报名功能的产品运营人员尤其可作为刚入门小程序开发者的工程化学习范本。系统覆盖活动展示、分类筛选、在线报名、微信支付、状态追踪、消息推送与后台管理等核心模块按页面、组件、工具函数和接口服务拆分目录能帮助理解从页面搭建到服务端交互的完整路径。压缩包为zip格式共74个文件、约81KB其中png图片负责界面图标与视觉元素js文件承载业务逻辑与API调用wxml/wxss构成页面结构和样式json用于应用与页面配置分类清晰便于按模块阅读和二次开发。目前已有898人学习参考对照微信官方文档可同步熟悉小程序生命周期、授权登录、支付及模板消息等开放能力也可作为活动类项目改造的直接基础模板。1. 微信小程序在线活动报名系统把报名从问卷星里抢回来一场线下读书会报名靠问卷星核对靠 Excel签到靠手写——三个系统之间来回倒数据漏一个人的名字就得翻聊天记录。把报名做成一个微信小程序不是给用户“填个表”这么简单背后是名额控制、审核流转、消息通知、现场签到一整条链路。这是一套适合企业 HR、社群运营、校园组织者使用的微信小程序在线活动报名系统活动发布、动态表单、名额限制、后台审核、订阅消息提醒、小程序码签到全部收进自己可控的后端里。数据自己掌握流程自己定义这才是自己做报名系统的理由。2. 先把数据模型立住活动、报名记录、用户三张表怎么设计才不返工报名系统的核心不是“报名”这个动作而是围绕一次活动产生的数据关系。见过不少新手的做法一张表存活动一张表存报名人员报名字段直接在表里加列。结果第二场活动要收集“是否素食”第三场要收“紧急联系人”表结构改一次接口改一次小程序端改一次一个周五晚上就没了。我一般会按“活动、报名记录、用户”三张表来做报名表里用一个 JSON 字段装用户的动态提交内容。这个设计一旦定下来后面所有功能都围绕它展开。2.1 活动表为什么 current_count 要放这里而不是用 COUNT(*) 现算先看活动表的建表语句CREATE TABLE activity ( id int unsigned NOT NULL AUTO_INCREMENT, title varchar(120) NOT NULL COMMENT 活动标题, description text COMMENT 活动详情, cover varchar(255) DEFAULT COMMENT 封面图地址, location varchar(255) DEFAULT COMMENT 活动地点, start_time datetime DEFAULT NULL COMMENT 开始时间, end_time datetime DEFAULT NULL COMMENT 结束时间, capacity int unsigned NOT NULL DEFAULT 0 COMMENT 名额上限0为不限, current_count int unsigned NOT NULL DEFAULT 0 COMMENT 已占名额, enroll_start datetime DEFAULT NULL COMMENT 报名开始时间, enroll_end datetime DEFAULT NULL COMMENT 报名截止时间, status tinyint NOT NULL DEFAULT 1 COMMENT 1草稿 2报名中 3已结束 4已取消, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_status_start (status, start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;很多教程会教你把已报名人数用SELECT COUNT(*) FROM enroll_record WHERE activity_id ?现算理由是“数据更实时”。这个思路在报名量小的时候没问题但一旦做名额校验、并发提交COUNT(*)会带来两个问题一是每次列表接口都要聚合查询活动一多响应就慢二是高并发下你查到的数量是旧值两个用户同时提交各自查到还剩 1 个名额结果都通过了。current_count字段就是用来对抗这种并发场景的。它本质上是冗余存储但报名系统里这个冗余值得用。所有名额增减都通过UPDATE activity SET current_count current_count 1 WHERE id ? AND current_count capacity完成一次原子操作既不锁表也不依赖事务隔离级别。status字段建议用数字枚举1 到 4 分别对应草稿、报名中、已结束、已取消。不要用字符串open、closedMySQL 里字符串索引比整型大小程序端判断也不方便。活动时间字段用datetime不要用timestamp避免 2038 年问题也方便直接映射到小程序的 picker 值。2.2 报名记录表form_data 用 JSON 存动态字段审核状态怎么流转用户提交的报名信息是整张表设计里最容易返工的地方。第一场活动要姓名、手机号第二场活动要公司、职位、饮食偏好第三场活动可能还要上传附件。如果为每场活动都建一张独立报名表后台管理端将无法统一处理。CREATE TABLE enroll_record ( id bigint unsigned NOT NULL AUTO_INCREMENT, activity_id int unsigned NOT NULL, user_id int unsigned NOT NULL, form_data json DEFAULT NULL COMMENT 报名表提交内容, status tinyint NOT NULL DEFAULT 1 COMMENT 1待审核 2已确认 3已取消 4已签到, remark varchar(255) DEFAULT COMMENT 审核备注, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_activity (user_id, activity_id), KEY idx_activity_status (activity_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;form_data用 JSON 类型里面存{name: 张三, phone: 138xxxx, company: 某某科技}不同活动的字段差异全部交给前端动态表单去约束后端只做统一校验——比如name不能为空、phone必须匹配正则。这样新增一场活动后台只需要配置字段列表不需要改表、改接口。uk_user_activity这个唯一索引是防重复报名的底线。就算小程序端忘记做按钮置灰、后端忘记做状态判断数据库这一层也能拦住同一个用户对同一活动插入第二条记录。报错会给Duplicate entry后端捕获后返回“你已报名过该活动”即可。用户表就比较简单了CREATE TABLE user ( id int unsigned NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, nickname varchar(64) DEFAULT COMMENT 昵称, phone varchar(20) DEFAULT COMMENT 预留手机号, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;openid是用户在微信生态里的唯一标识由wx.login的 code 在后端换取前端永远拿不到完整 openid。用户表不存密码、不存 token登录态靠后端自己下发一个session_token维护。注意openid必须加唯一索引否则同一微信用户重复登录会生成多条记录。三张表的关系一句话总结活动表管“一场活动能收多少人”用户表管“谁来了”报名记录表管“这个人在这场活动里填了什么、处于什么状态”。报名状态从 1 到 4 流转待审核可以被后台改为已确认或已取消签到后进入已签到状态不允许从已取消跳回已确认这个校验放在后端接口里。3. 小程序端从登录到提交报名wx.login、动态表单与防超卖接口数据模型定好后小程序端要解决三件事拿到用户身份、渲染报名表单、把数据安全地写进数据库。这里每一步都有容易翻车的地方尤其是登录和名额控制。3.1 wx.login 换 openid手机号不一定非要授权先说最常见的登录流程。小程序端调用wx.login拿到一个临时 code把它发给后端后端用 code 调用微信的接口换取 openid然后返回自定义登录态// 小程序端app.js onLaunch wx.login({ success: (res) { wx.request({ url: ${API_BASE}/api/login, method: POST, data: { code: res.code }, success: (loginRes) { const { token } loginRes.data.data; wx.setStorageSync(token, token); } }); } });// 后端Node.js 示例 const axios require(axios); async function code2Session(code) { const { data } await axios.get(https://api.weixin.qq.com/sns/jscode2session, { params: { appid: 你的appid, secret: 你的secret, js_code: code, grant_type: authorization_code } }); if (data.errcode) throw new Error(微信登录失败: ${data.errmsg}); return data.openid; // data.session_key 这里不需要存 }很多初学者会试图把session_key存进数据库其实报名系统根本用不到。session_key是用来解密手机号和敏感数据的只在需要的时候临时拿一下即可不落库能少一份泄露风险。后端拿到 openid 后查用户表不存在就插入一条新记录然后生成一个随机的token存 Redis 或内存里过期时间设 7 天小程序端后续请求带着这个 token。关于手机号这里要提醒一句新版基础库下小程序获取手机号已经不是一个免费能力需要企业主体认证且按次数计费。如果你的报名系统不是强实名场景完全没有必要接入手机号授权组件直接在动态表单里加一个“手机号”输入框用户自己填后端校验 11 位数字即可。这样既省钱又不会因为资质问题卡审核。3.2 动态表单报名字段由后台下发前端按类型渲染动态表单的做法是活动详情接口返回一个form_fields数组每个字段指定类型、是否必填、选项列表。小程序端拿到数组后循环渲染用户填写的内容存进一个对象提交时整体传给后端。// 活动详情接口返回的结构 const formFields [ { key: name, label: 姓名, type: input, required: true, placeholder: 请输入真实姓名 }, { key: phone, label: 手机号, type: input, required: true, placeholder: 用于接收活动通知 }, { key: company, label: 公司/单位, type: input, required: false }, { key: diet, label: 用餐偏好, type: radio, options: [标准餐, 素食, 忌口], required: false }, { key: remark, label: 备注, type: textarea, required: false, maxlength: 200 } ];对应的 WXML 片段用wx:for循环字段根据不同 type 渲染不同组件view wx:for{{formFields}} wx:keykey classform-item text classlabel{{item.label}}/text input wx:if{{item.type input}} value{{formValue[item.key]}} placeholder{{item.placeholder}} bindinputonFieldInput >Page({ data: { formFields: [], formValue: {} }, onLoad(options) { wx.request({ url: ${API_BASE}/api/activity/${options.id}, success: (res) { this.setData({ formFields: res.data.data.form_fields }); } }); }, onFieldInput(e) { const key e.currentTarget.dataset.key; this.setData({ [formValue.${key}]: e.detail.value }); }, onFieldRadio(e) { const key e.currentTarget.dataset.key; this.setData({ [formValue.${key}]: e.detail.value }); } });这里有两个细节值得注意。第一radio-group的bindchange返回的value是选项的字符串值不是索引所以提交时直接拿formValue序列化即可。第二textarea在真机上存在层级问题如果报名页需要弹窗或悬浮元素建议用cover-view处理或者把备注字段放到最后一屏避开悬浮元素。3.3 提交报名的事务顺序先占名额再插记录这是全系统最核心的一段逻辑。很多人写报名接口时习惯先查SELECT current_count FROM activity WHERE id ?再判断是否小于capacity最后UPDATE加一。这个流程在并发下必超卖。正确的做法是把“占用名额”和“写入报名记录”放在同一个数据库事务里而且更新名额的 SQL 自带条件判断// 后端报名接口核心逻辑 const db await pool.getConnection(); await db.beginTransaction(); try { const [updateResult] await db.execute( UPDATE activity SET current_count current_count 1 WHERE id ? AND current_count capacity, [activityId] ); if (updateResult.affectedRows 0) { throw new Error(该活动名额已满); } await db.execute( INSERT INTO enroll_record (activity_id, user_id, form_data) VALUES (?, ?, ?), [activityId, userId, JSON.stringify(formData)] ); await db.commit(); } catch (err) { await db.rollback(); throw err; }这条UPDATE语句是防超卖的闸门。current_count capacity条件让数据库在加一之前先判断是否还有名额而InnoDB的行锁保证同一时刻只有一个事务能更新这一行。第二个事务到达时发现条件不满足受影响行数为 0直接判满员。整个过程没有SELECT和UPDATE之间的空隙不会出现两个请求同时读到“还剩一个名额”的经典问题。注意INSERT要在名额更新之后执行这是因为万一插入失败回滚名额也会跟着回滚不会出现“名额被占了但报名记录不存在”的脏数据。前端做双重保险提交时加一个submitting标志位防止重复点击但数据库这层才是底线。4. 管理端与消息通知审核、名单导出、订阅消息一个都不能少报名系统不是用户提交完就结束的。后台要能看到谁报名了、要不要审核、如何通知用户这三件事决定这套系统能不能真正取代问卷星。4.1 管理端接口与页面待审核列表怎么拉管理端可以做成小程序内部的隐藏页面也可以做成简单的 Web 页面。核心接口就两个拉取报名列表和更新报名状态。报名列表要支持分页因为一场活动的报名人数可能上千一次性返回会撑爆内存。// 后端报名列表接口 app.get(/api/admin/activity/:id/enrolls, async (req, res) { const { page 1, pageSize 20, status } req.query; const where [activity_id ?]; const params [req.params.id]; if (status) { where.push(status ?); params.push(status); } const [rows] await db.execute( SELECT * FROM enroll_record WHERE ${where.join( AND )} ORDER BY create_time DESC LIMIT ? OFFSET ?, [...params, pageSize, (page - 1) * pageSize] ); res.json({ code: 0, data: { list: rows.map(row ({ ...row, form_data: JSON.parse(row.form_data) })), page: Number(page), hasMore: rows.length pageSize } }); });这个接口有几个字段需要留意pageSize建议固定 20 或 50小程序端用onReachBottom触发下一页加载状态筛选用数字因为status在数据库中就是数字直接用字符串2比较不会有问题但传给前端时转成数字更好。form_data是 JSON 类型MySQL 驱动返回的可能是字符串要JSON.parse后再返回给前端。管理页面里列表加载更多可以复用小程序端的常规分页方案data.page递增onReachBottom里判断hasMore再请求下一页。这正好是微信小程序页面列表加载更多的典型场景——注意别把hasMore写成loadMore语义不清晰新接手的人容易误解。审核接口也很直接// 后端更新报名状态 app.post(/api/admin/enroll/:id/status, async (req, res) { const { id } req.params; const { status, remark } req.body; const allowedTransitions { 1: [2, 3], // 待审核 - 已确认 / 已取消 2: [3, 4], // 已确认 - 已取消 / 已签到 3: [], // 已取消 - 不允许变更 4: [] // 已签到 - 不允许变更 }; const [rows] await db.execute( SELECT status FROM enroll_record WHERE id ?, [id] ); if (!rows.length) return res.json({ code: 1, message: 记录不存在 }); const current rows[0].status; if (!allowedTransitions[current]?.includes(status)) { return res.json({ code: 1, message: 不允许的状态流转 }); } await db.execute( UPDATE enroll_record SET status ?, remark ? WHERE id ?, [status, remark || , id] ); res.json({ code: 0 }); });状态流转表放在后端做白名单校验比前端隐藏按钮可靠得多。有人直接调用接口把待审核改成已签到后面签名记录都会乱掉。4.2 订阅消息一次订阅一次推送引导时机决定了触达率活动通知是报名系统的刚需。微信小程序里能主动推送用户的只有订阅消息而且限制很明确一次订阅授权只能推一条消息且订阅时机必须是用户主动触发。所以订阅引导必须放在两个位置错过基本等于通知白做。第一个位置是报名成功后立刻弹出授权。用户刚完成报名正在兴头上顺手点“允许”的概率很高。// 报名成功后的订阅引导 wx.requestSubscribeMessage({ tmplIds: [模板ID_活动开始提醒], success(res) { // 用户点击允许后后端保存订阅凭据等活动开始前推送 if (res[模板ID_活动开始提醒] accept) { wx.request({ url: ${API_BASE}/api/subscribe, method: POST, data: { templateId: 模板ID_活动开始提醒, activityId: this.data.activityId } }); } } });注意wx.requestSubscribeMessage必须在用户点击事件里调用不能放在onLoad里否则会被微信直接拒绝。第二个位置是用户打开“我的报名”列表时对“待审核/已确认”状态的活动补一次订阅引导因为报名成功页用户可能已经划走了。下发的逻辑放在后端。比如活动开始前 24 小时用一个定时任务扫描所有已确认状态的报名记录再调用订阅消息接口逐条推送。字段的填充值要和模板里的定义一一对应// 发送订阅消息 const res await axios.post(https://api.weixin.qq.com/cgi-bin/message/subscribe/send, { touser: openid, template_id: templateId, page: pages/detail/index?id${activityId}, data: { thing1: { value: activityTitle.slice(0, 20) }, // 标题限制20字 time2: { value: formatTime(activityStart) }, // 时间限制24小时制 thing3: { value: location.slice(0, 20) } } });模板字段有长度限制thing类型最多 20 个字符time必须是2019年10月1日 15:01这种格式。不做截断和格式化就发微信会返回错误码 47003参数不匹配。这块属于典型的“小细节坑整晚”的模块建议把模板字段格式写成一个工具函数统一处理。下发失败的处理也要提前想好。用户如果退订了小程序或者订阅凭据过期会返回 43101 用户拒绝接受消息。这种失败不能重试直接记一条日志跳过即可不要无限重试否则容易触发微信的接口限频。5. 上线前必看在线报名小程序最容易翻车的五个坑这套系统我自己做过不止一次每次上线前都有一批固定的问题反复出现。这里挑五个最典型的按“现象、原因、解决”写清楚希望能帮你少加一次班。5.1 名额超卖100 个名额报了 103 人现象活动页面显示还剩 2 个名额最终报名成功的有 103 人。原因报名接口先查再改SELECT和UPDATE之间有间隙。两个请求同时查到当前人数是 99都判断还能报于是各插入一条记录。解决用UPDATE activity SET current_count current_count 1 WHERE id ? AND current_count capacity作为闸门受影响行数为 0 时直接返回“名额已满”。这条语句是原子操作InnoDB 行锁会排队处理并发请求。注意配合事务使用名额更新成功后插入报名记录插入失败则回滚名额自动释放。5.2 手机号获取接口新基础库下默认收费别在审核前被发现现象开发阶段用手机号组件一切正常审核时被驳回理由是“涉及获取用户隐私信息但未说明用途”或者干脆接口调用返回费用不足的错误。原因新版基础库下button open-typegetPhoneNumber获取手机号能力已经改为付费接口个人小程序无法开通企业主体也需要单独签约并预充值。很多教程还在用几年前的免费方案。解决报名系统里如果不需要强制实名直接在动态表单里放一个手机号输入框用正则校验位数。如果业务确实需要快速填写评估一下每次调用的费用再决定是否接入。从投入产出比看绝大多数活动报名场景用表单输入就够了省下的费用可以多租一个月云服务器。5.3 类目审核个人主体做不了在线报名类目选不对必驳回现象小程序提审后收到通知说“当前涉及文化娱乐/线下活动需选择‘生活服务 生活服务 活动报名’类目个人主体不支持”。原因微信对“线上报名、预约”类功能卡得比较严。个人主体的小程序只能做资讯展示、工具类不能做面向公众的活动报名。企业主体也需要选择匹配的类目并可能要求提供相关资质。解决如果只是公司内部活动或者小范围社群活动把小程序定位改成“企业内部工具”限制访问范围用企业主体的认证账号提审。如果是面向公众的付费报名先确认营业执照经营范围里有没有“会议及展览服务”或“文化艺术活动策划”没有的话尽快补充经营范围变更否则审核通过率很低。开发前先到微信后台提交类目审核等结果下来再开始写代码避免返工。5.4 订阅消息发不出去一次订阅只能推一条别把授权藏太深现象活动前一天后端定时任务跑完日志里大量 43101 用户拒绝接受消息最终只有三分之一的人收到了提醒。原因一是订阅引导时机不对用户报名后没看到授权弹窗就关掉了页面二是用户一次订阅只对应一条消息如果你报名成功推了一条活动提醒就发不出去了。解决把订阅授权放在报名成功的回调里这是用户意愿最强的时刻。同时在“我的报名”页面里对已确认状态的活动加一个“接收提醒”按钮让漏掉的用户有机会补授权。后端发订阅消息前检查模板调用额度推一条之前要确定这条消息值得用掉这次授权——报名成功通知和活动开始提醒选一个推。5.5 时间字段的坑Picker 返回值直接入库比时区问题还常见现象后台设置活动时间为2025-06-01 09:00小程序端 picker 选择后传回的是2025-06-01 09:00字符串存进数据库后列表页显示的时间比预期少了 8 小时。原因picker返回的字符串本身没有时区概念后端按 UTC 解析或者前端在展示时做new Date(str).toLocaleString()会因本机时区设置产生偏移。另外datetime类型的值在 JS 里new Date(2025-06-01 09:00)会被当作本地时间但某些后端库连 MySQL 时会转为 UTC 存储。解决统一用时间字符串入库YYYY-MM-DD HH:mm:ss格式原样写入datetime字段不给 JS 的Date对象解析的机会。前端展示时也直接展示字符串不做new Date转换。需要比较时间时比如判断报名是否截止用new Date(enroll_end).getTime()与Date.now()比较注意enroll_end先拼成YYYY/MM/DD HH:mm:ss格式再解析避免 iOS 底下-分隔符不被兼容的老问题。6. 进阶用小程序码做现场签到把报名记录导出成 Excel报名系统做到能上线、能审核、能通知只完成了 80%。真正让运营省心的是活动当天的签到环节以及活动结束后的名单归档。这两个功能代码量不大但体验提升非常明显。签到方案我推荐用带参数的小程序码。后端为每一条已确认的报名记录生成一个 scene 参数内容是${activityId}_${enrollId}然后调用微信的接口生成小程序码图片提前发给用户保存。活动现场摆一个二维码立牌用户扫自己的码小程序端解析 scene 里携带的活动 ID 和报名记录 ID调签到接口将状态从已确认改为已签到。后端生成小程序码的代码const cloud require(wx-server-sdk); cloud.init(); exports.main async (event) { const { scene } event; // 格式: 12_345 const result await cloud.openapi.wxacode.getUnlimited({ scene: scene.slice(0, 32), // scene 最长 32 字符 page: pages/checkin/index, checkPath: false, envVersion: release }); return result.buffer; // 前端拿到 Buffer 转成图片临时路径 };scene参数是二维码的唯一标识但长度限制 32 字符而且只能包含数字、字母和部分符号所以不要放 openid 这类长字符串。用${activityId}_${enrollId}这种短拼接最稳妥。page必须是小程序里已存在的页面路径envVersion指生成正式版还是体验版的码测试阶段用trial上线后改release。如果用户扫的是体验版二维码注意真机调试下无法扫码打开这是个容易混淆的点。活动结束后运营需要一份 Excel 名单。常见做法是由后端生成 CSV 文件前端直接下载。从form_dataJSON 里取字段时注意某些字段可能缺失比如旧活动没有“公司”这一项导出时要给默认空字符串避免undefined拼进 CSV 里变成一行坏数据。const rows await db.execute( SELECT form_data, status, create_time FROM enroll_record WHERE activity_id ? AND status IN (2, 4), [activityId] ); const header 姓名,手机号,公司,状态,报名时间\n; const body rows.map(row { const data JSON.parse(row.form_data); const statusText { 2: 已确认, 4: 已签到 }[row.status] || 未知; return [ data.name || , data.phone || , data.company || , statusText, row.create_time ].join(,); }).join(\n); res.setHeader(Content-Type, text/csv; charsetutf-8); res.setHeader(Content-Disposition, attachment; filenameenrolls.csv); res.send(\ufeff header \n body);注意 CSV 文件中文在 Excel 里打开会乱码所以要在开头加\ufeffBOM 头。如果字段值里包含逗号、换行符导出前要统一清洗加双引号包裹。依赖第三方 xlsx 库会减少这类问题但对报名系统来说CSV 已经足够微信里直接打开也方便。这套报名系统整个跑下来我的习惯是把“先占名额、再插记录”这段事务逻辑做成独立的代码片段每次新项目直接复用然后记住订阅消息的授权时机比模板内容更影响触达率。活动报名看起来是个小需求但名额控制、审核流转、消息触达、现场签到串起来后它就是一套完整的业务系统。希望这些经验能帮到你少踩几个我踩过的坑。本文还有配套的精品资源点击获取