报名数据处理关键在“写得准、验得严、防得住”：表单需带模型前缀，load()须检查返回值，validate()依赖rules()与scenarios()协同，防重靠数据库唯一索引+代码层IntegrityException捕获，支付与报名须通过order_no绑定并设超时机制。
Yii开发活动报名系统时，报名数据处理的关键不在“写入快”，而在“写得准、验得严、防得住”。很多项目上线后出现重复报名、空字段入库、支付未关联等问题，根源常是模型层和控制器层的数据流转没对齐。
表单字段名必须带模型前缀
Yii默认要求POST数据键名为模型名[字段名]，比如User模型的username字段，前端input的name属性得写成name="User[username]"。若前端传的是{username: "a"}这种扁平结构，控制器里就得显式传空字符串：$user->load($data, '')。不加这句，load()直接返回false，但很多人忽略返回值判断，接着就调validate()——结果永远“验证通过”，脏数据直奔数据库。
验证四环节缺一不可
Yii的validate()静默返回true，往往因为以下任一环节缺失：
• 模型属性在rules()里定义了，但没在scenarios()中声明该字段属于当前场景；
• rules()里写了'on' => 'create'，但控制器里没执行$model->scenario = 'create'；
• 数据根本没进模型——load()失败却没检查；
• JSON请求没手动解析：需先$raw = $request->getRawBody()，再$data = Json::decode($raw)，最后$model->load($data, '')。
防重复报名要靠数据库+逻辑双保险
仅靠PHP层判断“用户是否已报过该活动”不可靠，高并发下仍有概率写入重复记录。正确做法：
• 数据库层面，在报名表（如registration）上建联合唯一索引：UNIQUE KEY `user_activity` (`user_id`, `activity_id`)；
• 代码层面，save()失败时捕获IntegrityException，检查错误码是否为1062（MySQL重复键），再返回友好提示，而非抛500；
• 若用ActiveRecord，可在beforeSave()中主动查一次self::find()->where(['user_id'=>$this->user_id, 'activity_id'=>$this->activity_id])->exists()，提前拦截。
支付与报名数据必须实时绑定
报名成功不等于支付完成。常见错误是把报名和支付拆成两个独立事务，导致“报了名但没付款”状态长期滞留。稳妥做法：
• 报名提交时生成一条status = 'pending'的报名记录，并附带唯一order_no；
• 支付回调接口收到通知后，根据order_no查出对应报名记录，原子性更新status = 'paid'并填充支付流水号；
• 后台定时任务扫描超时pending记录（如30分钟未支付），自动置为'expired'并释放名额；
• 前端报名页可加倒计时，提示“剩余支付时间”，避免用户误以为已锁定名额。
