最近把一个微信小程序竞赛报名系统做完了交付前后折腾了小半个月踩了不少坑。这个项目本身不算复杂但涉及的业务流程比想象中多比赛创建、报名填报、后台审核、人数统计、消息通知一环扣一环。如果你也在做类似的项目或者正准备接这类私活这篇应该能帮你省不少事尤其是那些平时文档里不会写清楚的边界问题和微信平台的隐性限制。简单介绍下这个系统能干什么。它解决的核心痛点是线下竞赛报名时填表混乱、统计费劲、通知靠吼。用微信小程序做报名入口参赛者扫码即用不用下载App不用注册新账号微信授权一下就能报名。管理员在后台创建比赛、设置报名起止时间和人数上限报名数据自动进库审核通过或驳回后用户能在小程序里看到结果。整个流程从发布到组队、报名、审核、通知全链路都串起来了。适合谁参考一是拿这类题目做毕业设计的学生二是在公司或学校内部需要快速落地报名场景的开发者三是想接外包单子的独立开发者。接下来我把这个系统的设计思路、数据库结构、小程序端实现、后台审核闭环以及部署上线后碰到的典型问题全部拆开讲。1. 项目背景与需求拆解1.1 为什么选微信小程序而不是网页或H5这是开工前第一个要想清楚的问题。竞赛报名过去有两种常见做法一种是Excel表发群里大家自己填最后统计时乱七八糟另一种是做个网页报名系统但使用门槛卡在推广上用户填个报名信息还要先打开浏览器、输入网址、注册账号很多人填到一半就放弃了。微信小程序在这条赛道上优势非常明显。首先是分发路径短用户扫一个码或者群里点小程序卡片直接就打开了不需要经历“下载App、安装、注册”这种高成本动作。其次是身份识别成本低微信小程序的wx.login可以直接换取用户的唯一标识 openid不需要用户单独注册一个账号对参赛者来说“零门槛”对开发者来说也省掉了一整套账号体系的开发量。第三是通知能力审核结果和赛前提醒可以通过订阅消息触达虽然现在订阅消息被限制成“一次性订阅”但在报名场景里恰好够用。当然选小程序也有代价。比如代码包有2MB大小限制比如关键接口必须配HTTPS合法域名再比如发布上线前要经过微信侧的审核。这些约束会在后文展开选型时心里有数就好别等到开发一半才来抱怨平台限制。1.2 角色与核心业务流程梳理竞赛报名系统里有三类角色对应三类需求角色核心诉求关键操作参赛者快速找到比赛、顺利报上名、随时看审核状态浏览赛事列表、填写报名信息、查看我的报名、取消报名管理员创建比赛、控制报名节奏、统计名单、通知结果发布赛事、审核报名、导出名单、发送状态通知开发者保障系统稳定、数据准确、合规上线维护数据表、排查并发与审核问题、跟进小程序审核业务流的核心可以拆成一条主线管理员创建比赛并设置时间与人数限制发布后用户在小程序端看到比赛点击报名并填写信息数据进入待审核状态管理员在后台逐条审核审核结果回写数据库用户在下一次打开小程序时看到最新状态同时收到一条订阅消息提醒。状态机的设计是这个项目里最容易忽略但最重要的事。比赛本身有状态草稿、报名中、报名截止、已结束报名记录也有状态待审核、已通过、已驳回、已取消。两个状态机都要在数据库里存字段前端页面根据状态决定按钮文案和可点击性。线下讨论需求时常常只谈“能报名就行”但实际上很多隐藏问题都出在状态流转上比如比赛截止后用户还能不能取消报名审核通过后还能不能修改报名信息这些都需要在设计之初就定清楚。我给这个项目定的规则是报名截止后不能提交也不能取消审核通过后信息锁定。1.3 需要预先确认的业务细节开工前一定要跟需求方确认清楚几个问题否则后面返工非常痛苦。第一报名是个人报名还是团队报名如果是团队赛表单里要加队伍名称和成员列表逻辑复杂度直接上一个台阶。第二是否需要限制人数上限超过上限后是禁止报名还是进入候补队列第三是否需要收费如果比赛要收报名费就涉及微信支付商户号接入个人主体小程序无法开通需要企业资质这个坑一旦踩进去格外烧时间。第四是否需要管理员审核有些比赛报名即通过那审核模块就可以砍掉简化整个流程。我这次做的系统包含团队报名和后台审核因为需求方明确说比赛有队伍人数限制还要人工确认参赛资格。如果一开始没把这些问清楚等到数据库建完、页面写完才发现要做团队字段改动量相当大——涉及用户表、报名表、前端表单、后台审核列表、导出名单五个地方。2. 数据库模型与接口设计2.1 核心数据表设计数据库我用的是云开发数据库因为部署省心不必单独买服务器开箱即用。但表结构的思路是通用的换MySQL、PostgreSQL也一样。整个项目一共三张核心表用户表、比赛表、报名表。用户表的设计很简单但有一个关键点要特别注意不要把微信昵称头像当成用户表主键用户真正的唯一标识是 openid它由微信分配与用户微信号绑定业务系统里所有与用户相关的查询都应该用 openid 关联。昵称和头像只是展示字段随时可能被用户更换或清空不能承担业务关联的职责。比赛表的核心字段包括字段类型说明competition_idstring比赛唯一ID前端路由参数titlestring比赛名称descriptionstring比赛介绍支持换行coverstring封面图地址team_limitnumber每队人数上限个人赛填1max_teamsnumber报名队伍总数上限signup_starttimestamp报名开始时间signup_endtimestamp报名截止时间statusstringdraft / published / endedcategorystring比赛分类如编程、数学、体育时间字段统一存时间戳而不是字符串。这一点主要是为了排序和比较方便前端拿到时间戳后自己格式化展示。如果存字符串“2024-05-01 09:00:00”在数据库里做大于小于比较时格式一旦不统一很容易出错。报名表是整个系统的核心它的字段设计决定了后续审核和统计是否顺利字段类型说明registration_idstring报名记录唯一IDcompetition_idstring关联比赛openidstring报名用户team_namestring队伍名称个人赛填个人名leader_namestring队长姓名leader_phonestring队长手机号membersjson团队成员列表字段为姓名和微信号statusstringpending / approved / rejected / canceledcreated_attimestamp提交时间reviewed_attimestamp审核时间remarkstring管理员驳回原因members 存成 JSON 数组是个人赛和团队赛统一的关键选择。如果不存JSON就得额外建一张team_member表报名时做事务性写入审核时再做联表查询复杂度明显上升。对于报名系统这个体量JSON字段完全够用导出名单时直接解析即可。2.2 接口清单与权限控制接口设计遵循“小程序端只做展示和提交核心判断放服务端”的原则。主要接口如下接口方法说明权限/loginPOSTwx.login 换 openid所有用户/competitionsGET比赛列表支持状态筛选与分页所有用户/competitions/:idGET比赛详情所有用户/registrationsPOST提交报名登录用户/registrations/mineGET我的报名记录登录用户/registrations/:id/cancelPOST取消报名报名本人/admin/competitionsPOST创建或更新比赛管理员/admin/registrationsGET按比赛查报名列表管理员/admin/registrations/:id/reviewPOST审核通过或驳回管理员登录接口是整个系统的基础。小程序端调用wx.login()拿到临时 code把 code 发给服务端服务端调用微信的 code2Session 接口换取 openid 和 session_key再把 openid 返回给前端存起来。这里有一个安全细节千万不要信任前端传上来的 openid正确的姿势是前端只传 codeopenid 由服务端解析后从接口响应里下发。如果直接把 openid 放前端请求体里传过来等于任何人都能伪装成别人。报名提交接口要重点防两件事重复报名和超员。重复报名靠数据库的唯一约束实现同一用户同一比赛只允许一条非取消状态记录云开发里可以用where查询配合add的原子性来兜底。超员判断则必须在服务端做用户点击报名时先查当前已通过加待审核的记录数再和max_teams比较。不要小看这一步线下同时有十几个人在报名时如果不加控制很容易出现“最后一个人也报名成功但实际已超员”的竞态问题。3. 小程序端开发实操3.1 项目结构与应用配置小程序端的目录结构我按业务模块划分避免全部页面堆在一起miniprogram/ ├── app.js ├── app.json ├── app.wxss ├── pages/ │ ├── index/ // 赛事列表首页 │ ├── detail/ // 比赛详情页 │ ├── signup/ // 报名表单页 │ ├── mine/ // 我的报名 │ └── admin/ // 管理端入口管理员可见 ├── components/ │ ├── empty-state/ // 空状态组件 │ └── status-tag/ // 状态标签组件 ├── utils/ │ └── request.js // 网络请求封装 └── api/ └── index.js // 接口定义app.json 里最值得强调的是 tabBar 配置。首页和“我的报名”作为两个 tab 比较顺手用户进来先看赛事列表报名后去第二个 tab 查状态。部分竞赛项目会把“我的报名”藏进个人中心但我实测下来两个 tab 对用户更友好因为报名后马上要查状态是高频动作入口越显眼越好。窗口样式上微信小程序顶部导航栏高度在不同机型上不一致尤其刘海屏和普通屏差距明显。处理这个问题的通用做法是获取系统信息里的statusBarHeight和menuButtonRect动态计算自定义导航栏的高度。但如果你不想自己写导航栏直接用默认导航栏就行别为了炫技引入自定义导航组件平白加一堆兼容代码。3.2 网络请求封装与统一错误处理这是小程序端被很多人忽略但极其重要的一层。我写了一个基于wx.request的 Promise 封装// utils/request.js function request(url, method, data, header {}) { return new Promise((resolve, reject) { wx.request({ url: getApp().globalData.baseUrl url, method: method, data: data, header: { content-type: application/json, Authorization: getApp().globalData.token || , ...header }, success(res) { if (res.statusCode 200 res.data.code 0) { resolve(res.data.data); } else if (res.statusCode 401) { // 登录态失效重新登录后重试 wx.showToast({ title: 登录已过期请重新进入, icon: none }); reject(res.data); } else { wx.showToast({ title: res.data.message || 请求失败, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常请稍后重试, icon: none }); reject(err); } }); }); }这里统一了错误提示业务代码里就不用每个页面都写一遍wx.showToast。401 的判断很关键微信小程序的登录态会过期用户在比赛列表页停留很久再点报名很可能 token 已经失效此时直接提示让用户重新进入页面比报一个莫名其妙的失败更友好。接口地址统一放在api/index.js里管理页面代码只调用语义化的函数比如getCompetitionList(page)、submitRegistration(data)。这样后期换接口地址或者加统一拦截逻辑只改一处。3.3 赛事列表页与分页加载赛事列表页是所有流量入口也是第一个要处理体验细节的地方。我使用的是onShow里刷新数据因为用户报名成功后返回列表页列表数据要反映最新状态用onLoad只在页面首次加载时触发数据会陈旧。分页加载这块微信小程序原生没有提供滚动加载的组件靠的是页面触底事件onReachBottom。实现起来就是维护一个page变量每次触底page再请求接口返回的数据判断是否还有下一页没有就显示“没有更多了”。这里有个细节onReachBottom的触发距离可以在页面 json 里配置onReachBottomDistance默认值是50px我实测列表页建议设成100px用户手指滑到底部附近就预先加载体验更顺滑。列表页还有一个绕不开的问题下拉刷新。小程序里启用页面下拉刷新很简单在页面 json 里把enablePullDownRefresh设为 true再监听onPullDownRefresh。下拉刷新时重置分页参数并重新请求数据回来后wx.stopPullDownRefresh()关闭刷新动画。这个操作看似基础忘了stopPullDownRefresh的话刷新动画会一直转圈测试时很尴尬。赛事卡片的展示要根据状态做差异化。报名中的比赛显示截止时间和剩余名额用高亮色突出“报名中”未开始的显示“即将开始”已截止的不显示报名按钮只留下“查看详情”。状态判断在前端做一次在后端再校验一次用户在截止时间前一秒点报名前端校验通过了提交到后端仍可能被拒这是正常的。3.4 报名表单页与提交逻辑报名表单页是用户和数据打交道最直接的地方也是工作量最大的页面。字段不一定全但每个字段都要有校验。我自己总结的校验原则是“前端校验保体验后端校验保数据”。姓名和队长的信息用输入框收集手机号要做正则校验。这里有个实打实的坑微信小程序的input组件在部分安卓机型上会出现输入光标错位的问题尤其是页面内容较长需要滚动时。解决办法是给input设置adjust-position相关属性或在bindfocus时手动滚动页面到输入框可见区域。不要觉得这是小概率事件我在真机上碰到过好几次。提交按钮的防重复处理很关键。用户弱网环境下点击报名请求还在路上又点一次就会产生两条报名记录。前端用变量锁定点击后立即把按钮状态设为 loading 并 disabled请求结束才恢复。同时后端也要做唯一约束双保险。代码大致长这样async handleSubmit() { if (this.data.submitting) return; this.setData({ submitting: true }); try { const data await api.submitRegistration({ competitionId: this.data.competitionId, leaderName: this.data.form.leaderName, leaderPhone: this.data.form.leaderPhone, teamName: this.data.form.teamName, members: this.data.form.members }); wx.showToast({ title: 报名成功等待审核, icon: success }); wx.redirectTo({ url: /pages/detail/detail?id this.data.competitionId }); } finally { this.setData({ submitting: false }); } }wx.redirectTo和wx.navigateTo的差别是redirectTo会关闭当前报名页防止用户返回后再点一次“报名”造成重复提交。这个细节是我踩过坑后才补的一开始用navigateTo结果用户报名成功后能返回到表单页重新提交一遍后台出现两条记录。3.5 我的报名与订阅消息“我的报名”页承担的是用户查询状态的核心需求。页面默认展示当前用户所有报名记录每条记录显示比赛名称、报名时间、当前状态。状态标签很重要待审核用黄色已通过用绿色已驳回用红色已取消用灰色用户一眼就能看明白。取消报名功能要加上限制如果比赛已经到截止时间取消按钮要隐藏审核通过后也不能取消因为管理员可能已经统计了名单。这些规则后端也验证前端只是提前拦截。订阅消息的接入是这个项目里做起来最繁琐的部分。微信要求先在小程序后台申请订阅消息模板审核通过后得到一个模板ID然后前端在合适的时机调用wx.requestSubscribeMessage让用户授权。我的做法是用户在提交报名成功的回执弹窗里顺带请求订阅消息授权文案写清楚“审核结果将通过微信通知您”这样转化率比事后突然弹授权高很多。审核通过后服务端调用微信的 subscribeMessage 接口推送结果。订阅消息有“一次性订阅”的限制用户授权一次只能接收一条消息。报名审核只有一次结果通知恰好匹配。但如果还要做赛前提醒就需要在合适时机再引导用户订阅一次这个在产品层面就要规划好别想着一条授权用到天荒地老。4. 管理端与报名审核闭环4.1 管理后台的功能规划管理端我做了两个入口一个是在小程序里给管理员角色看到的管理页面另一个是独立的Web后台。小程序里的管理页面适合管理员在手机上快速审核Web后台则适合批量操作和统计导出。两个入口共用同一套数据库和接口不增加额外复杂度。管理功能核心是三大块。第一块是赛事管理管理员可以创建新比赛、编辑已有比赛、手动关闭报名通道。创建比赛时要能配置报名开始时间、截止时间、人数上限、队伍人数限制、比赛介绍和封面图。第二块是报名审核按比赛维度筛选报名记录每条记录显示报名人信息、队伍信息、提交时间管理员操作通过或驳回驳回时填理由。第三块是数据统计在赛事实时展示报名总数、待审核数、通过数、驳回数帮助管理员判断报名进度。Web后台的名单导出功能用的是服务端生成Excel。前端点击导出按钮服务端查库生成xlsx并返回下载链接。如果图省事直接在小程序里做导出小程序端无法直接下载二进制文件到本地体验很差这个功能放在Web后台是最合理的。4.2 审核并发与人数上限控制审核操作有一个特别容易翻车的地方管理员审核的速度和报名人数上限之间的关系。假设比赛限报20队当前待审核记录有5条管理员一口气把这5条全部点通过但实际系统里已经有18条通过记录了再点通过就会超员。解决办法是在审核接口里做剩余名额校验伪代码如下async reviewRegistration({ registrationId, action, remark }) { const reg await db.collection(registrations).doc(registrationId).get(); if (action approve) { const competition await db.collection(competitions).doc(reg.competitionId).get(); const approvedCount await db.collection(registrations) .where({ competitionId: reg.competitionId, status: approved }) .count(); if (approvedCount.total competition.maxTeams) { // 返回“名额已满无法通过” } } // 更新状态 }这个校验必须放在服务端因为管理员可能同时打开多个浏览器标签页批量操作前端拦截不靠谱。批量审核时也要注意前端虽然会把多条记录一起提交但后端每一条都要独立做名额校验确保“先到先得、按审核时间排序”。这里我实际踩过的一个坑是明确了“待审核记录不占名额审核通过时才占名额”的规则后排队的报名用户可能等很久才知道结果。所以我在报名详情页里加了一行提示“报名后请耐心等待审核人数达到上限后未审核的报名可能无法通过”提前管理用户预期后续客诉少了很多。4.3 通知触达的几种方案对比审核通过或驳回后怎么触达用户我对比过三种方案。第一种是小程序订阅消息这是首选。用户在小程序内完成过授权且消息模板提前在小程序后台申请好了服务端调订阅消息接口推送用户能收到微信服务通知。优势是成本低、流程闭环劣势是一次性订阅限制用户如果不授权就发不出去。第二种是公众号模板消息。如果团队本身有服务号且用户关注了公众号可以通过公众号模板消息推送审核结果。但这里有个问题用户的 openid 在小程序和服务号体系下是不一致的需要用户在报名时同时提供微信号或引导关注公众号然后做openid关联操作成本高。这个方案我没有采用只做了记录以后如果用户量大再考虑。第三种是短信通知。这需要买短信服务且用户要填手机号成本高一些覆盖面广但对报名系统来说性价比低。我的建议是订阅消息作为主通道同时在小程序“我的报名”页提供一个负一屏的刷新入口哪怕用户没授权订阅消息只要打开小程序就能看到状态不至于漏掉通知。5. 部署、测试与常见问题排查5.1 从代码到可体验的版本代码写完后距离真正能发给别人用还差几步配置。小程序上传到微信后台生成体验版二维码在“成员管理”里把测试人员的微信号加进体验成员对方扫码就能进入体验版。这里有个常见误区开发者工具里的模拟器能跑不代表真机一定没问题所以体验版一定要发给多个不同机型的用户试收集几天反馈再迭代比直接提审上线稳妥得多。正式上线前服务器域名必须配置HTTPS并且要在微信公众平台的“开发管理-服务器域名”里把接口域名加进request合法域名。不加这个配置模拟器里能跑真机一请求就报request:fail url not in domain list。调试阶段可以在开发者工具的“详情-本地设置”里勾选“不校验合法域名”但当心这个设置是“本地设置”每台开发机都要勾一次而且换工具版本后可能要重新勾选很容易在真机预览时忘记。开发版、体验版、正式版三者的区别要清楚开发版只能在开发者工具里打开体验版可以由体验成员扫码打开且无需经过微信审核只有正式版才需要提交代码审核。如果项目着急验证直接上传体验版给团队内部试用就行不必先过审核关卡。5.2 常见问题与排查速查表整理一下我在这个项目里以及同类型项目中出现过的常见问题按表格形式给出方便你对照排查。问题现象原因解决方案真机请求报url not in domain list服务器域名未配置到小程序后台白名单将接口域名加入 request 合法域名开发工具取消域名校验仅限调试用上传代码提示包体积超2MB主包文件过大图片或组件冗余启用分包加载把报名详情页、证件照页面等放入分包压缩图片用wx.getUserProfile拿不到头像昵称微信已经收回常驻授权能力引导用户自行填写头像昵称或使用“头像昵称填写能力”官方方案订阅消息授权后仍然收不到通知授权一次性用完或模板ID配置错误检查模板ID是否与申请到的模板匹配检查用户是否重复授权报名成功后提交两条记录前端重复点击或未用 redirectTo 关闭页面按钮加 loading 锁定状态提交成功关闭报名页后端加唯一约束模拟器正常但真机白屏基础库版本过低或使用了不兼容API在 app.json 中配置libraries或升级基础库版本后重测部分安卓机型输入框光标错位input 组件与页面滚动冲突监听 focus 事件手动pageScrollTo滚到输入框位置列表页下拉刷新后动画一直转未调用wx.stopPullDownRefresh()接口结束后必须关闭刷新动画比赛报名截止后还能提交仅前端隐藏了按钮后端没校验报名提交接口必须校验当前时间是否在signup_start和signup_end之间云开发数据库提示权限不足数据库默认权限是“仅创建者可写”报名页读取比赛列表被拒绝配置数据库权限为“所有用户可读创建者可写”敏感集合单独处理新手最容易被绊住的就是域名校验和包体积超限。包体积这个坑比较可惜因为多数时候不是代码多而是图片多。封面图一定不要直接放本地静态资源建议传到云存储或CDN代码包只保留必要的几张图标。我这边的比赛封面图全部走云存储链接主包控制在1.2MB左右稳稳过关。5.3 报错日志与线上问题定位小程序上线后最痛苦的事情是线上报错你不知道用户那边发生了什么。开发者工具的控制台和真机调试只能覆盖你自己设备上的情况真实用户的各种机型、各种操作路径会带来意想不到的问题。我给项目加了一个简单的上报逻辑在wx.onError和app.js的onError里捕获异常调用了一个日志上报接口记录用户openid、页面路径、错误堆栈和微信版本号。日志表结构也不复杂就是报错信息加时间戳加用户身份。有了这些日志用户在群里反馈“我这边打不开”你先查后台日志看一眼有没有对应记录再让用户配合提供微信版本很多时候几分钟就能定位。这个操作不费什么力气但对线上项目的维护体验提升巨大。有些私活项目根本不接入监控上线后一有问题只能远程帮用户看效率极低这一点我强烈建议加上。日志系统还能反哺功能优化。比如我发现日志里有大量“点击报名后接口504”的记录顺着追查是报名接口查询人数上限时数据库在高峰期响应变慢。后来给报名相关的查询字段加了索引情况立刻好转。这种判断如果没有日志支撑只能靠猜。6. 测试要点与项目交付心得6.1 真机测试清单交付前我列了一份真机测试清单每项都要在至少一台安卓、一台iPhone上验证。这种交叉验证很重要因为wx.showToast的图标、订阅消息授权弹窗样式、input 聚焦交互在两端表现都有差异。测试清单包括赛事列表分页加载是否顺畅下拉刷新后数据是否正确报名表单字段校验是否生效弱网环境下重复点击提交是否会产生重复记录订阅消息授权后能否收到推送“我的报名”页状态刷新是否正确管理员审核通过后用户端状态是否同步比赛截止后报名按钮是否禁用取消报名后剩余名额是否回滚。其中弱网测试最容易被忽略。微信开发者工具里可以模拟网络状态把网络改成弱网或断网看页面会不会报错、按钮会不会卡死。我在弱网测试时发现了一个问题报名请求发出后网络中断按钮已经锁定了用户不知道发生了什么。后来在提交逻辑里加了一个超时提示网络异常时弹“网络异常请稍后重试”同时解锁按钮让用户可以再试一次。这类细节很影响用户对系统的信任感。6.2 数据安全与隐私合规作为接私活或者做毕设项目数据安全同样要过一遍脑子尤其是报名表里的手机号、姓名这类个人信息。我的处理原则是能少收集就少收集非必填字段一律不收集。手机号是联系参赛者需要必须收集但其它无关字段如身份证号、住址、紧急联系人一律不放进表单。另外数据库的开权限要小心。使用云开发时默认权限如果设置成“所有用户可读”那比赛信息暴露没问题但报名记录如果开放了读权限用户通过云开发控制台就能看到别人的报名信息这是严重事故。正确做法是比赛集合开放所有用户可读报名集合只允许本人读管理员通过管理端接口访问不直接开放客户端读库权限。审核操作全部走后端接口数据库的写权限能关就关。管理员的口令或登录机制也别做得太简单至少要用一个管理员专用登录页密码不要明文存在任何地方。如果项目预算允许接入一个简单的验证码登录也行。我这次用的是专属口令加验证码双重校验口令可定期更换避免长期有效泄露。6.3 从竞赛报名系统到通用活动报名系统的扩展思路项目收尾后回头看这套系统的可扩展性其实很强换一个壳就可以支撑多种场景。例如把比赛表改成活动表字段从比赛名称替换成活动名称报名表保留队伍信息和审核状态就是一个通用的活动报名系统。校园招聘会、社团纳新、讲座预约、运动会项目填报都是同样的业务模型。进一步扩展的话一个方向是接入微信支付做付费报名。需要企业主体的小程序并开通微信支付商户号开发量主要在支付回调处理和退款流程上。另一个方向是做证书或电子票的发放审核通过后系统生成一个带二维码的参赛凭证参赛者到场时扫码签到这就能把报名系统和线下签到串联起来。还有一个方向是多轮筛选第一轮报名通过后进入下一轮面试或测试报名表增加阶段字段和备注字段即可。从我个人的体会来说竞赛报名这类业务“看起来简单做起来细节多”真正花时间的不是在页面上而是在状态流转、并发控制、权限管理和线上故障排查里。每次交付完一个这样的项目我都会把测试清单和踩坑记录整理成自己的文档库下次再做类似系统时能省下大量时间。如果你正在做类似的项目建议也多留一份这样的记录哪怕只是Markdown文件几个月后回头看都会觉得值。