一场商学院活动，报名页要承载的东西比看上去多。300 个名额，拆成 6 个场次，每场 50 人；报名人分校友、在校生、企业嘉宾三类，不同身份看到的说明文字不一样；还有候补。
名额怎么扣
第一版我们想简单了：每场一个剩余数字，报名成功就减 1。测试时两个人同时点最后 1 个名额，都成功了。又是先查后写那个老问题。
后来跟生鲜那次一样，把判断交给数据库：
UPDATE sessions SET seats = seats - 1 WHERE id = 某场 AND seats > 0
后端看 rowCount，0 就进候补表。候补不占名额，按提交时间排，有人取消时定时任务从候补里取第一个，发一封邮件让他 24 小时内确认。这个「确认再转正」是客户加的，怕候补的人早忘了这事。
身份那点岔子
三类身份一开始放在一个下拉里，必填。结果后台看数据，有一批人选了「其他」，备注里写着自己是「校友家属」。客户说这类人其实归企业嘉宾那一档。我们没改选项，改了文案，在下拉旁边加了一行小字说明家属怎么选。之后「其他」就少了。
导出比页面费劲
活动前一天，项目组要名单。不是一张总表，是按场次分 6 个 sheet，每个 sheet 里按身份排好、带手机号和单位，打印出来给签到台用。我们写了个导出脚本，用 PHP 生成 xls，一个场次一个 sheet，表头固定 7 列。第一版忘了把候补单独列出来，签到台那边差点漏人，补了一个「候补」sheet。
那次之后，导出格式我们一律先让对方发一份他们以前用过的表，照着做，不自己设计。
上线那天
7 月 20 号上午 10 点开放。我们几个在后台刷每场的剩余数，头 20 分钟掉了 100 多个，其中第 3 场最快，40 分钟报满，开始进候补。中间有个小插曲：有人用同一个手机号报了两场，客服打电话过去，对方说想两个都听听。规则是不允许，后台做了合并，留了一场。
中午之前 6 场里满了 4 场。剩下的没再管，页面自己跑着。
