很多人对“路演系统”的第一反应是这不就是个报名工具吗可真上手做的时候才发现报名只是开胃菜投票模块才是最容易让人翻车的重头戏。我自己带过的项目里凡是“演出报名投票”类的需求最后十有八九都卡在同一个地方——人一多就慢、票一多就乱、一上线就被刷。这篇文章就把我从零搭建一套路演演出报名投票小程序系统的完整过程拆开讲包括数据库设计、并发扣名额、防刷投票、榜单实时统计这些核心环节的踩坑记录和最终方案给正在做课设、毕设或者真实活动运营的朋友一个可以直接抄作业的参考。1. 项目定位与整体设计思路1.1 先想清楚系统到底要解决什么问题很多人的思路是“先做个报名功能再试试投票”然后做着做着就发现两边都在迁就最后哪个都没做好。我建议一开始就摆正定位这套系统的本质是一场演出赛事的流量管理工具报名解决的是“谁能来、能来多少人”投票解决的是“谁表现好、谁该被看见”这俩是完全不同的业务逻辑。报名业务的特征是高频写、低并发但怕超卖。几十个名额一瞬间被抢完是常态投票业务的特征是读多写少、怕作弊几百上千人盯着同一个榜单刷访问热点非常集中。把这两个特征想清楚后面的表结构、缓存策略、接口设计就都有了依据。我当时给自己定了三条业务规则简化成一句话就是报名靠“锁”投票靠“频”榜单靠“缓”。1.2 技术选型为什么最终选了小程序加 Spring Boot技术选型上我纠结过好几轮。第一版考虑过纯H5但发现两个痛点一是演出场景下用户需要快速操作H5要先扫码再等加载体验上天然弱于小程序二是微信生态的原生能力比如订阅消息通知、openid 唯一标识H5 很难直接拿到。最终定下微信小程序 Spring Boot MySQL Redis 的组合这也是目前校园和中小型活动系统比较稳妥的搭配。这套组合的理由很直接小程序端天然带微信登录体系不需要自己做注册登录同时打开即用、不占内存用户心理门槛非常低。Spring Boot做后端管理逻辑、对接微信接口都比较成熟社区资料多遇到问题不容易卡死。Redis负责扛高并发的读请求和频率限制同时用它的有序集合做实时榜单性能远高于直接查数据库。MySQL存最终数据保证报名记录、投票明细这些核心数据不会丢。1.3 整体模块划分与核心流程这套系统我从一开始就拆成了四个一级模块用户端小程序、管理端后台、后端服务接口、数据库与缓存层。用户端面向报名者和投票者管理端面向活动主办方后端服务统一暴露接口数据库与缓存层承载所有数据读写。核心业务流有三条报名流程浏览活动→微信授权登录→填写报名表单→提交锁定名额→收到报名成功通知、投票流程查看节目列表→点击投票→后端校验资格→Redis计数→异步落库、管理端数据流查看报名列表→导出名单→查看实时榜单→触发数据刷新。三条流程互相独立但共用同一套用户体系和活动配置数据后面所有技术实现都是围绕这三条流程展开的。2. 报名模块的设计与实现并发扣名额、防重复、表单设计2.1 报名信息字段怎么定才能不返工报名表单的字段设计看似简单实际上是最容易来回改的东西。我的经验是能被系统自动获取的字段绝不让人填能复用的字段绝不单独存。第一版我贪多求全一股脑放了姓名、学号、学院、手机号、微信号、年级、参赛组别、节目名称结果用户一提交就懵了前后端联调也麻烦。后来我重新梳理将其分为三类自动填充字段用户唯一IDopenid 映射、微信昵称、头像。这些在用户授权后接口直接返回不做成表单项。必填业务字段姓名、手机号、参赛组别、节目名称。这些是主办方真实要用的信息缺一不可。选填扩展字段节目简介、指导教师、备注。这部分字段控制 UI 展示为可选项不校验必填。核心体验逻辑是报名表必须“短平快”三步以内完成。参赛者不是来填问卷的表单越长流失率越高。我当时实测过超过 5 个必填项后报名成功率明显下降。写完字段后我还做了一次校验规则梳理——手机号用正则校验座机和手机两种格式组别用下拉选择避免脏数据。2.2 并发抢名额的核心实现Redis 预扣减加数据库锁兜底演出类活动最怕“万人同时抢 30 个名额”这种场景下直接操作数据库判断“剩余名额 0”再执行插入百分百会超卖。我第一版就吃了这个亏压测时 500 个并发请求进来名额 50 个结果成功报名了 63 人。后来改成 Redis 预扣减加数据库锁兜底问题才彻底解决。核心逻辑分三步走Redis 预热活动创建时把名额总数写入 Rediskey 为activity:quota:{activityId}值为剩余人数。预扣减用户提交报名时先执行DECR命令如果返回值小于 0说明名额已满直接返回“已报满”并执行INCR回补。数据库落库预扣减成功后才执行数据库插入插入时加唯一索引防重复并用SELECT ... FOR UPDATE锁住活动行做最终校验。这里有一个非常关键的心得Redis 预扣减不能用GET判断完再SET必须用DECR这种原子操作否则多线程环境下依然会有并发漏洞。Redis 单线程执行命令的特性天然保证了原子性扣名额这种操作交给它是最省心的。数据库锁兜底是因为 Redis 万一被清空或者重启库存数据会不准确所以每次报名还要在 MySQL 里做一次真实剩余名额校验。2.3 防重复报名唯一索引与幂等设计普通做法是在代码里先查报名表再判断“这用户是不是报过了”但这种方式在并发下完全不靠谱——同一用户同时点了两次提交两个请求都查到“未报名”然后两条记录都插进去了。我的解决方案非常直白在数据库层面加唯一索引。我设计的报名表registration里把user_id activity_id建成唯一索引这样不管同时来多少个请求数据库最多只能插入一条。代码里的查重只是用户体验层面的优化提前提示“您已报名”真正的防线是索引。同时接口层加了一层幂等机制前端提交时生成请求唯一流水号request_id后端先查 Redis 里有没有处理过这个request_id没有才执行业务逻辑处理完把request_id写入 Redis 并设置过期时间。这样即使用户断网重试、手滑连点也不会产生重复报名数据。这套组合拳实测下来很稳压测时 1000 并发请求同一用户的重复提交最终报名表里只有一条记录Redis 侧也没有出现负数名额。2.4 报名模块的异常处理用户看到友好提示系统留足排查线索报名的异常处理我吃了不少亏第一版是“系统错误”“服务器异常”一类模糊提示结果用户卡在页面不知所措我这边也不知道到底发生了什么。后来我专门设计了异常体系业务异常名额不足、重复报名、活动未开始向前端返回业务码和友好提示日志里打印业务码。系统异常数据库挂了、Redis 超时统一返回“报名火爆请稍后重试”日志里记录完整异常栈同时发送告警到管理端。降级策略Redis 不可用时报名功能自动降级为“数据库直连 行锁”模式保证服务不宕但不保证绝对不超卖。这里特别要强调降级逻辑的取舍。我当时纠结了一下Redis 挂了到底要不要继续接报名最终决定是“降级但是不熔断”因为演出报名通常是短时高峰宁可偶尔允许超卖一两个名额让主办方手动调整也不能让整场活动变成无人能报名。主办方看到超卖也能理解用户全被挡在门外才是事故。3. 投票模块的设计与实现防刷策略、实时榜单、高并发读3.1 投票规则定义一开始就把边界条件写死投票是这套系统里最容易出幺蛾子的地方业务规则的模糊会给开发埋无数坑。我第一版只有一个简单的规则“每人可投 3 票”结果上线后各种问题一个人可以投同一个节目三票吗投票结束后允许改票吗半夜被人刷票怎么办后来我把规则做了严格定义直接写进后端配置中心前后端共用同一套配置投票资格只有完成微信授权登录的用户才能投票游客不可投。投票次数每场活动限定每人投 3 票可投给同一节目或不同节目这里按业务需求设置。投票窗口期只有活动处于“投票中”状态才开放投票接口开始前或结束后一律拒绝。不可撤票投票成功后不可撤销、不可修改避免反复变更给统计带来脏数据。规则写清楚后后端逻辑就变成了纯校验加计数的流程不用每个接口都猜“这样改会不会影响其他逻辑”。我最深的一个体会是投票规则代码本身很简单难的是规则理解一致。管理端号称“每人每天一次”用户端理解成“每人整个活动一次”这种不一致在后端是会炸的。3.2 防刷票的落地请求频率、唯一性、异常模型三重防护防刷是投票模块的重头戏做好它需要层层递进。我采用的是三层防护模型每一层拦截不同类型的攻击第一层请求频率控制。单个用户投票接口的调用频率限制在每 5 秒最多 1 次超出就直接拒绝。实现上用 Redis 记录用户最后一次投票时间戳配合滑动窗口或令牌桶算法做限流。这一层主要挡的是“脚本连点”这种最原始的攻击。第二层用户维度 IP 维度的行为分析。单账号一天内投票次数超过 50 次直接封禁投票权限同一 IP 下超过 20 个不同 openid 投票自动拉入观察名单。这一层挡的是通过批量注册小号刷票的行为。第三层异常模型识别。对投票记录做聚合分析算法层面统计每分钟投票总数超过历史均值三倍以上触发熔断。比如往日每分钟投票量在 100 上下突然飙到 1000系统自动进入“验证模式”要求投票者先完成滑块验证才能继续投。这个设计在实际运营中很管用——真人用户被拦一下加个验证就过了刷票机器则很难模拟滑块的轨迹特征。3.3 实时榜单为什么不直接查数据库演出类场景有个特点评委和观众都盯着实时榜单看每隔几秒刷新一次。如果每次都去 MySQL 做GROUP BY聚合统计几千人的活动就可能把数据库打崩。这里就要用到 Redis 的ZSet有序集合。我的实现思路是每个节目创建一个 key格式为vote:ranking:{activityId}。用户成功投票后执行ZINCRBY vote:ranking:{activityId} 1 {programId}。前端榜单接口直接读取ZREVRANGE WITHSCORES拿到降序排列的前 20 名毫秒级返回。同时每 10 分钟将 ZSet 的快照同步到 MySQL 的program_vote_count表用于历史归档和最终结算。这里一定要提醒Redis 的 ZSet 是最终一致性方案万一 Redis 重启且没来得及持久化榜单数据可能丢失一部分所以必须配合定期同步。我的方案是每 10 分钟同步一次活动结束时强制触发一次同步并锁定榜单保证最终的最终结果与数据库一致。3.4 投票结果的统计口径与数据校验投票结束后主办方第一件事就是要最终结果。这里的坑是线上页面显示的和导出 Excel 里的可能对不上——因为用户投票后 Redis 已经计数了但数据库异步落库还没完成两边数据不一致。我后来加了一套对账机制从 MySQL 投票明细表做真正意义上的完整统计每个节目的准确票数。与 Redis ZSet 的当前分数做对比差额超过 5% 触发告警。触发告警后自动补偿任务会查询投票明细表重新计算得分写入 ZSet 中以保证页面展示的数据修正。说白了Redis 扛住了实时展示的高性能需求但最终的权威数据永远以数据库为准——凡是涉及钱、奖、名额的绝不能只看 Redis。4. 后端服务与数据库设计表结构、接口清单与微信登录4.1 数据库表结构的关键设计这套系统我最终落地了 6 张核心表这里只挑最有代表性的几张讲设计思路用户表 user主键用户 ID关联微信 openid。注意 openid 必须建唯一索引同一个微信号在小程序里 openid 是固定不变的这是整套系统识别用户身份的基石。另外建议单独存一份 unionid 字段备用如果同一个主体下有多个小程序unionid 才能打通不同小程序的用户体系。活动表 activity存活动基本信息和状态。核心字段包括活动名称、报名开始/结束时间、投票开始/结束时间、总名额、已用名额、活动状态未开始/报名中/投票中/已结束。活动状态是驱动整个业务流转的关键后端接口每次都会校验当前时间与状态的一致性。报名表 registration唯一索引设为(user_id, activity_id)加上唯一的request_id做幂等控制。业务字段包括组别、节目名称、手机号、备注。投票记录表 vote_record每一条投票记录都是明细数据核心字段为投票人 ID、节目 ID、活动 ID、投票时间。建联合索引(activity_id, program_id, user_id)方便统计某个节目的投票人数同时防止同一个人给同一节目投多次。节目表 program挂载在活动下存节目名称、表演者、所属组别、封面图等。这里注意节目表和活动表是一对多关系不要只依赖前端传节目名称一定要有 program_id 做关联否则后续统计全部乱套。4.2 后端接口清单与实现逻辑接口设计遵从“能用 5 个接口解决的事绝不拆成 8 个”的原则。以下是最终版的接口清单GET /api/activity/{id}获取活动详情和当前状态POST /api/registration提交报名幂等校验→Redis 预扣名额→落库GET /api/program/list?activityId获取节目列表和实时票数POST /api/vote投票身份校验→频率校验→Redis 计数→异步落库GET /api/ranking?activityId获取实时榜单GET /api/admin/registration/list管理端导出报名名单每个接口都要做三层校验参数校验、身份校验token 中的用户 ID业务状态校验活动时间窗口。校验顺序有讲究——一定要先做身份校验再做业务校验否则未登录用户请求一次接口就触发一次业务逻辑容易被刷。拿投票接口举例它的最终实现顺序是从请求头拿到 token解析用户 ID。检查活动状态是否为“投票中”。检查用户今天已投次数达到上限直接返回“投票次数已用完”。校验目标节目是否属于该活动。执行 RedisZINCRBY增加票数。放入 MQ 异步队列最终写入 MySQL 投票明细表。前四步都是天折回路第 5 步才是真正的写入第 6 步异步化解决高并发场景下数据库写压力过大的问题。4.3 微信登录code2session 换 openid 的全流程小程序端调用wx.login()拿到临时code传给后端后端再调用微信接口code2session拿到用户的 openid 和 session_key然后把 openid 与自家用户表匹配生成自定义 token 返回给前端。后续所有接口请求都带着 token后端解析 token 拿到用户 ID。这里有几个关键细节code只能用一次且 5 分钟内有效后端必须做防重放校验同一个 code 被使用两次直接拒绝。session_key永远不要返回给前端它是用于解密敏感信息的留在后端即可。生成的 token 建议放在 Redis 里并设置过期时间我设的是 7 天前端在请求拦截器里统一捕获 401 状态码自动重新调用wx.login()刷新 token。我在实际开发中还加了一个小优化用户进入小程序后先从前端存 localStorage 里的 userInfo 中判断是否已登录已登录就直接放行未登录才走wx.login()流程。这样比起每次启动都重新 code2session请求量能砍掉一大截。4.4 引入消息队列投票异步落库的正确姿势一开始我的方案是投票后同步写 MySQL结果压测到 200 并发时 MySQL 的连接池就满了接口耗时飙升到 8 秒。后来改成消息队列异步落库数据库写入压力顿时被打散。推荐消息队列从 RabbitMQ 和 RocketMQ 里选一个。RabbitMQ 生态成熟、社区资料多中小型项目完全够用RocketMQ 性能更好、事务消息强适合后续要扩容的场景。我当时选用了 RabbitMQ 的原因是部署简单一条命令就能跑起来开发环境调试也方便。核心逻辑是投票接口处理完 Redis 计数后把{activityId, programId, userId, voteTime}封装成一条消息发送到vote.queue消费者监听队列批量消费并批量插入数据库。消费者要注意配置手动 ACK 和重试机制消息处理失败不能直接丢弃否则投票数据就凭空消失了。5. 小程序端实现登录态管理、页面交互、体验优化5.1 小程序页面结构三大核心页面一个都不能少小程序端我最终设计了四个核心页面首页活动列表、活动详情页含报名入口、节目投票页、个人中心页。这四页的比例几乎是所有此类小程序的标配少一个用户使用时就会觉得功能不完整。首页做的是活动卡片流展示活动封面、名称、报名状态和剩余名额。活动详情页是重头戏上面是活动信息中间是报名按钮下面展示活动流程说明。这里要注意报名按钮的状态要跟后端活动状态联动未开始时置灰“尚未开始”报名中显示“立即报名”名额满显示“已报满”活动中显示“投票入口”。四种状态前端要用接口返回的activityStatus字段控制千万不要写死。投票页是整个小程序交互最复杂的部分。我的设计是列表页展示节目卡片每个卡片上有节目名、表演者、实时票数、投票按钮。用户点击投票后按钮变灰票数加一同时顶部的“剩余票数”同步减一。用户当日票数耗尽后所有按钮统一置灰并提示“今日票数已用完”。5.2 登录态的管理与请求封装别再到处写 wx.request很多新手写小程序每个页面里都直接wx.request然后一遍遍处理 token 过期、错误提示、loading 状态代码冗余到爆炸。我在这个项目里从一开始就封装了统一的请求模块所有请求统一走request()方法自动携带 header 中的 token。全局拦截 401 状态码自动重新登录后重放请求。全局拦截 500 状态码统一弹出“服务开小差请稍后再试”的 toast。封装loading参数传true时自动弹出 loading请求完成后自动关闭。封装完成后每个页面里的业务代码非常干净比如提交报名只需写这样一段const submitRegistration async () { const data { activityId: this.data.activityId, name: this.data.form.name, phone: this.data.form.phone, programName: this.data.form.programName, group: this.data.form.group }; const res await request({ url: /api/registration, method: POST, data, loading: true }); if (res.code 0) { wx.showToast({ title: 报名成功, icon: success }); // 刷新活动状态 this.refreshActivityStatus(); } };5.3 页面数据刷新与状态同步不要每个按钮都去请求一次接口节目投票页的票数展示一开始的笨办法是每 3 秒调一次榜单接口结果流量耗费严重体验还卡。后来我改成“本地 服务端”双轨状态管理本地状态用户进入页面时从接口拉一次初始榜单渲染到列表用户自己投票后本地票数先 1按钮立即置灰给用户即时反馈。服务端状态管理端后台和用户端榜单每 30 秒才刷新一次真实数据刷新时以 Redis 为主、MySQL 兜底。这样用户端操作响应是毫秒级的后端也不需要面临每秒几千次的轮询请求。要提醒的是本地优化不能覆盖服务端真实数据必须每隔一段时间把本地数据和接口数据做一次校准比如用户在投票页停留超过 30 秒后再进入页面时强制重新拉取榜单。5.4 体验优化细节点位提醒、骨架屏、分享卡片小程序体验上的小事容易积少成多我至少做了三个改进报名/投票结果即时反馈报名成功不是单纯弹个 toast而是跳转一个专门的报名成功页页面展示报名编号并明确指引“投票通道将在活动开始后开放”。这样用户知道自己报上了也清楚下一步要做什么。骨架屏加载节目列表页用骨架屏替代传统的转圈 loading视觉上流畅很多也让用户感觉页面更快。分享卡片定制小程序默认分享卡片只有标题和缩略图我定制了分享文案和图片用户转发时直接带上活动名称、时间和“点击即可报名”的引导语裂变效果比默认分享好上好几倍。6. 管理后台与运营支撑名单导出、实时榜单、活动风控6.1 管理后台的定位数据看板优先操作功能其次管理后台是做给主办方用的他们关心的只有三件事有多少人报了、榜单什么情况、名单怎么导出来。我把管理后台首页做成了看板风格——顶部是总数卡片左侧是趋势折线图中间是实时榜单表格。报名列表页支持条件筛选按组别、按报名状态、按关键词检索支持一键导出 Excel。导出功能我特意做了异步化——数据量大时先在后台生成文件导好后通知用户下载避免请求超时。管理端还有一个重要功能是活动状态的切换开关。主办方可手动将活动从“报名中”切为“投票中”或“已结束”切换逻辑后端要校验时间合法性比如报名中切投票中时先检查报名人数是否大于零。6.2 实时榜单的落库与周期归档前面提过 Redis ZSet 扛实时榜单但管理后台最终结算时必须读 MySQL 的权威数据。我在管理后台榜单页面做了一个“归档快照”按钮点击后触发两个动作把 Redis 当前 ZSet 分数同步到 MySQL 的program_vote_count表。将同步结果写入活动日志表保留现场快照防止作弊争议。归档后管理后台的榜单只从 MySQL 读取不再依赖 Redis。这样即使后续 Redis 数据丢失最终结果也不会受影响。我在实际运营中还加了一条规则——活动结束后自动触发归档不用等主办方手动点按钮。6.3 活动风控的快速介入一键冻结与拉黑投票活动中最容易出现集中爆发刷票的情况。管理后台我专门加了一个“风控操作栏”包含三个功能按钮冻结单个用户的投票权限、封禁单个节目 30 分钟、全场投票暂停 10 分钟。这三个操作都是秒级生效的后端对应的逻辑是冻结用户Redis 写一个冻结 key后续该用户投票时直接拒绝。封禁节目Redis 写节目状态 key前端列表该节目按钮置灰后端投票接口判断节目标记并拒绝。全场暂停Redis 写活动级暂停 key投票接口第一个校验就是这个 key存在即拒绝。为什么要用 Redis 而不是数据库改字段因为紧急风控要求秒级生效Redis 写 key 是 O(1) 操作而修改数据库还要考虑连接池、事务和主从同步延迟。这是我最想强调的一个经验应急操作设计必须追求最短路径。7. 常见问题与排查技巧实录7.1 报名人数超过名额却显示报名成功这个问题的根因往往是预扣减与落库之间没有强一致校验。排查时先看 Redis 里剩余名额是否为负数再看registration表是否有比名额多的记录。解决办法是把预扣减逻辑改成“先DECR校验再在事务里SELECT ... FOR UPDATE活动行做最终确认”同时核对activity表的已用名额字段是否有被并发写串。经验教训是逻辑分层越清晰越容易排查。报名链路是“幂等校验 → Redis 预扣 → SQL 锁校验 → 落库”每一步失败了都能定位到具体环节。7.2 用户反映票数投不上页面上却显示已投票这类问题最常见的是前端本地状态与后端不统一。用户点了投票按钮前端立刻票数 1、按钮置灰但后端接口因为频率限制或票数耗尽拒绝了前端没有处理失败回滚。解决方法是前端在投票失败时回滚本地票数和按钮状态同时给出明确错误提示。我还在请求封装层加了一条规则业务码非零一律走通用的失败弹窗避免静默失败。7.3 微信订阅消息发送失败我踩过的坑是订阅消息一次性订阅的授权限制。wx.requestSubscribeMessage只能让用户订阅一次后端发送一次后 token 就失效了。如果用户第二场活动也想收到通知需要再次发起订阅。我的方案是在报名成功页再次拉起订阅授权保证用户在需要时完成订阅而不是在报名入口就提前引导订阅。经验是任何引导订阅请求都要放在用户“即将获得价值”的时刻转化率远高于在首页硬推。7.4 小程序审核被拒的常见原因演出报名投票类小程序在微信审核时最容易踩的雷是类目选择错误。我用的是“工具 信息查询”类目结果被驳回了两次因为投票属于典型的社区互动。后来归到“社交 社区”类目并补了相关资质说明才通过。另外凡是涉及用户生成内容UGC的小程序都要提供内容审核机制我在投票文案上加了关键敏感词过滤并在举报入口做了用户举报功能才算过关。7.5 数据统计对不上账“Redis 显示 2000 票数据库只有 1800 票”这种不一致几乎都是异步落库丢失导致的。排查分两步先看 MySQL 投票明细表里有没有对应的投票记录再看 MQ 消费日志看消息是否被丢弃。第二步是确认消费者是否配置了手动 ACK——如果没有消息在服务器重启时会丢失。我的最终方案是消费端做了“幂等 补偿”双保险消费前查重、消费失败进死信队列、定时任务扫死信队列重新投递。8. 后续扩展方向与个人经验总结这套系统做完后我在实际运营中又迭代了好几个版本这里挑几个值得扩展的方向分享给大家。方向一票数加权与小组评分。单纯的观众投票很难反映艺术质量我给系统加了一套“评委票 观众票”双轨制评委账号由主办方后台手动配置评委票权重是观众票的 5 倍。实现时只需要在投票接口里增加账号维度的权重字段Redis 计数时按权重加值即可改动不大但效果显著。方向二报名与签到的打通。很多演出活动线下需要核销签到我给系统加入了报名成功后生成二维码的功能主办方用另一部手机扫码即可核销。二维码内容是报名记录的加密 ID扫码后后端判断是否已核销并返回结果整个过程不需要引入专门的扫码设备。方向三弹幕与实时互动。演出直播时观众可以在小程序里发弹幕这个功能实现上要换成 WebSocket 长连接或小程序wx.connectSocket复杂度上了一个台阶。但如果活动本身有直播需求互动功能的留存效果确实比单纯的投票好很多。最后再分享一点亲身体会这类“报名 投票”系统单看任何一个功能都不算难难就难在把两端用户端和管理端、三态未开始、进行中、已结束、三库Redis、MySQL、MQ串成一个闭环还要时刻提防并发和防刷这两个隐形炸弹。我的建议是动手写代码之前先把活动和投票规则用文字列清楚哪怕多花一晚上把边界条件写详尽也比后期返工修 bug 省一百倍时间。希望这篇文章能给准备做类似系统的朋友一个相对完整的技术参考少走几步弯路。