Yii2更新操作需结合条件更新、唯一约束和请求标识实现幂等：必须用状态校验（如WHERE id=1001 AND status=1）或乐观锁，配合anti-token校验与Redis原子操作，禁用按钮仅为前端辅助。
Yii2 更新操作本身不带天然幂等保障，UPDATE 语句若没加限制条件，重复提交很可能导致字段被多次叠加、状态被反复翻转，甚至业务逻辑错乱（比如订单状态从「待支付」→「已支付」→「已取消」→「已支付」）。必须结合条件更新 + 唯一约束 + 请求标识三者落地。
UPDATE 必须带明确的 where 条件且含状态校验
直接写 UPDATE user SET balance = balance + 100 WHERE id = 123 是危险的。用户点两次，余额就加两百。正确做法是把业务状态作为前置条件：
- 用乐观锁思路：只允许在特定状态下更新，例如
UPDATE order SET status = 2, updated_at = NOW() WHERE id = 1001 AND status = 1（仅当原状态为「待处理」才允许更新为「已处理」） - Yii2 中推荐用
updateCounters()或updateAll()配合条件数组，避免手写 SQL 出错 - 检查
ActiveRecord::update()返回值：它返回影响行数，为 0 表示未更新成功（可能是状态已变），此时应拒绝响应而非静默忽略
后端必须校验 anti-replay token（非 CSRF Token）
Yii2 默认的 _csrf 只防跨站伪造，不防用户自身重复提交。你需要额外生成一次性的防重 token：
- 表单页加载时，调用
Yii::$app->security->generateRandomString(32)生成 token，存入Yii::$app->session或 Redis，同时写入表单隐藏域： - 提交时在 Controller 中校验：
if (!$this->validateAntiToken($post['anti_token'])) { throw new BadRequestHttpException('重复请求'); } - 校验逻辑必须原子：读 token → 删除 token → 执行业务，三步不可拆；Redis 推荐用
GETDEL或 Lua 脚本保证
数据库层加唯一索引或业务联合键
对更新类操作，唯一索引虽不能阻止 UPDATE 多次执行，但能兜底防止“重复生成关联记录”这类副作用：
- 例如订单支付成功后要插入一条
payment_log，给(order_id, payment_type)加联合唯一索引，重复插入会抛出IntegrityException - 捕获该异常，在 Yii2 中用
try...catch (\yii\db\IntegrityException $e)统一转成「操作已完成」提示，而不是报错 - 注意：索引字段必须覆盖所有能标识“同一笔业务”的维度，时间戳单独加索引无效
前端禁用按钮只是辅助，不能替代后端验证
很多人在 submit 事件里设 btn.disabled = true 就以为万事大吉，其实这根本挡不住刷新页面后重提、Postman 模拟、F5 回退再提交：
- 禁用按钮只解决“用户手抖”，不是安全机制；一旦后端没 token 校验或条件更新，照样出事
- 如果用了
yii2-lock-form这类插件，注意它默认只锁表单 DOM，不生成/校验服务端 token，仍需自己补全后端逻辑 - 不要在
finally里无条件恢复按钮可用——若后端返回「已处理」，按钮应保持禁用并显示成功状态，而不是让用户再点一次
真正难的是 token 生命周期管理：用户开两个标签页填同一张表单，一个提交成功，另一个再提就会失败；这时候要不要自动刷新 token？怎么通知前端？这些细节不处理好，体验反而更差。
