年会投票系统开发记

上个月接到个棘手的活儿——要给公司年会搞个实时投票系统。当时行政部的小张抱着电脑冲进我工位，脑门上的汗珠在日光灯底下亮晶晶的。我盯着她发来的需求文档直嘬牙花子：要支持500人同时在线、20秒刷新一次数据、还得防刷票。这阵仗，比我去年给小区超市做的会员系统可复杂多了。

先摸清楚水有多深

翻出抽屉里吃灰的笔记本，我把市面上常见的方案列了个遍。微信小程序投票虽然方便，但数据控制权在腾讯手里；自己搭服务器倒是自由，可光买云服务就得吃掉预算的大头。这时候突然想起前阵子技术沙龙上听人提过的Serverless架构，眼睛突然亮了起来。

技术选型的弯弯绕

跟技术总监老李蹲在吸烟区吞云吐雾时，他弹了弹烟灰："别光看参数，要考虑突发流量。"这话点醒了我——年会上董事长突然要临时加个投票环节的情况，去年就发生过三次。

• 前端用Vue3搭界面，轻量又灵活
• 后端选腾讯云的云函数，省去服务器配置
• 数据库用Firebase实时库，数据同步快
• 防刷机制准备做三层验证：设备指纹+行为分析+IP限制

掉坑里才能长记性

真正动手开发那天，我在公司熬到凌晨三点。云函数的冷启动问题比想象中严重，第一次测试时3秒才返回数据，急得我差点把键盘给砸了。后来翻遍官方文档，发现可以设置预置并发，这才把响应时间压到800毫秒内。

防刷系统更是状况百出。开始设计的滑块验证，被测试组的同事用脚本5分钟就破解了。后来改成动态算术题，结果财务部的王姐打电话投诉："让我算34+58？我这岁数心算不得半分钟啊！"后还是折中用了短信验证码+设备绑定的方案。

那些意想不到的幺蛾子

• 年会当天现场网络波动，导致20%用户连接中断
• 某部门领导把投票链接误发到外部合作群
• 凌晨数据库突然告警，查出来是定时任务没关闭

惊险的是正式投票前两小时，突然发现同个WiFi下的设备会被误判成刷票。我蹲在会场后台，把膝盖当桌子改代码，硬是在开场前10分钟推送了热更新包。

现在回头看这些坑

技术总监后来跟我说，这套系统竟然撑住了年会现场823人的并发请求。茶水间的阿姨有次碰见我，还夸投票页面"比抢红包还流畅"。不过要说实在的收获，是行政部现在团建吃火锅都会叫上我——他们觉得程序员改bug和涮毛肚一样，讲究火候和手法。

窗台上的绿萝又抽新芽了，阳光透过叶片在代码编辑器上投下斑驳的光影。收拾工位时翻出当时画的架构图，边角还沾着咖啡渍。也许下次该试试把日志监控系统加上，谁说得准明年年会又要整什么新花样呢？