报名、审核、支付和签到经常被做成几个互不关联的按钮，结果是同一报名重复审核、支付成功却仍显示待确认，或者已签到的记录又被取消。把流程明确成状态机，是降低这些边界问题的第一步。
先定义允许的状态迁移
可以从“待审核、已通过、已拒绝、待支付、已确认、已取消、已签到”这些业务状态中选择实际需要的状态，并明确每种状态允许由谁、通过什么操作进入下一状态。免费活动不需要支付状态；无需审核的活动也不应经过审核节点。
每次迁移都保留业务证据
- 记录操作人、操作时间、原状态、新状态和备注。
- 审核通过或拒绝时，以报名记录的当前状态作为更新条件，避免并发请求重复处理。
- 涉及名额扣减时，在事务中完成状态迁移与名额更新；失败时整体回滚。
- 对外部支付回调使用订单号和平台交易号做幂等校验，重复通知不重复生成报名或收入记录。
状态日志与当前状态应分开保存：当前状态便于查询，日志用于审计和排查。管理员补录或撤销也应走明确操作并留下原因，而不是直接改数据库字段。
把异常路径纳入验收
测试重复点击、审核期间名额已满、支付超时后补回调、用户取消后再次支付、签到后尝试退款等情况。每个异常都要定义最终状态及用户提示。流程先求清晰，再考虑把审批、通知和对账拆成可独立扩展的服务。
