多角色多端状态控制与锁控制

抽象场景描述

在实际业务系统中，我们经常遇到同一条数据记录被多个角色、多个客户端并发操作的情况。典型如“内容审核”、“任务状态更新”、“订单流转”等场景。

本案例抽象为以下数据模型：

id | user_id | word | review_status | review_opinion | review_user_id

这张表用于记录用户提交的内容（word），由后台审核人员进行审核处理，审核状态存储在 review_status 字段，审核意见写入 review_opinion，而 review_user_id 表示执行审核操作的管理员 ID。

很多时候可能都没有 review_user_id 这个内容，但是为了严谨和安全这个审核人也是需要加上的。

在实际业务中，存在以下典型角色：

• 普通用户：提交或修改 word 内容，触发审核流程。
• 审核人员（运营）：基于 review_status 审核用户提交内容，可能打回或通过。
• 系统服务或定时任务：自动更改 review_status，例如长时间未审核的内容自动打回。

具体场景举例

1. 用户 A 提交文案 word，此时 review_status = 0（待审核）。
2. 同时运营 B 正在审核该内容，正准备将状态置为 2（已通过）。
3. 此时，用户 A 发现错误，在运营未审核前修改了内容，review_status 被用户接口自动回退成 0（待审核），运营端页面未刷新，仍提交 2（已通过）。
4. 结果：状态冲突，最终保存结果不一致，导致运营看到通过，用户看到未通过，系统状态混乱。

状态流转：

[至少有 5 个内容，但是 0和 1 可以在某些场景 共用】

review_status	状态含义	备注说明
-1	草稿	用户刚填写内容，尚未提交审核
0	待审核	用户点击“提交审核”按钮后进入审核流程
1	审核中（可选）	审核人员点进详情页或锁定审核任务
2	审核通过	内容通过
3	审核不通过 / 打回	审核失败，需要用户修改后重新提交

1. 用户 A 编辑文案 word，初始为 review_status = -