应使用 beforewrite 钩子在 save() 前触发合规审核，调用外部 api 时设超时并捕获异常，仅审核 content 等富文本字段，审核失败时设置 $this->error 并返回 false，使控制器可通过 geterror() 获取具体原因。
模型保存前如何触发内容合规审核回调
ThinkPHP 模型本身不内置内容审核逻辑，所谓“自动回调”必须手动在 save() 前插入校验环节。直接覆盖 save() 方法风险高，推荐用事件或模型钩子。
常见错误是把审核逻辑写在控制器里，导致复用性差、漏掉批量更新或关联保存场景；更糟的是在 afterSave 中做同步审核——此时数据已落库，违规内容已暴露。
- 优先使用
beforeWrite钩子：它在数据写入前触发，且能中断保存流程（返回false即终止） - 若需调用外部审核 API（如腾讯云文本审核），建议设超时（
5s内）并捕获异常，避免阻塞主流程 - 注意字段过滤：只对
content、title、remark等富文本字段审核，跳过status、user_id等非内容字段
审核失败时怎么阻止数据入库并返回具体原因
不能只抛异常或简单 return false，否则上层无法区分是网络超时、审核驳回，还是字段缺失。ThinkPHP 的 validateFailException 不适用于这种业务级拦截。
实操建议是在 beforeWrite 中主动设置模型错误信息，并让 save() 返回 false：
public function beforeWrite()
{
$content = $this->getData('content');
$result = $this->callAuditApi($content);
if ($result['code'] === 4001) { // 审核不通过
$this->error = '内容包含敏感词，请修改后重试';
return false;
}
if ($result['code'] === 0) {
$this->data['audit_status'] = 'passed';
return true;
}
$this->error = '审核服务暂时不可用，请稍后重试';
return false;
}
这样控制器里可统一处理：if (!$model->save()) { echo $model->getError(); }
异步审核结果怎么安全回填到原记录
同步调用审核接口在高并发下容易拖垮响应，但异步回填又面临「记录被改」或「重复回调」问题。核心矛盾在于：审核系统回调时，原始记录可能已被编辑甚至删除。
- 回调接口必须带唯一标识，建议用
record_id:timestamp:hash组合（如123:1715894220:abc123），避免仅靠id匹配 - 回填前先查最新版本：
where('id', $id)->where('audit_status', 'pending')，防止覆盖人工修正后的状态 - 更新语句加条件锁：
update table set audit_status = ?, audit_at = ? where id = ? and audit_status = 'pending'，用影响行数判断是否成功回填 - 回调失败要进重试队列（如 Redis List），但最多重试 3 次，避免死循环
为什么不能在 Observer 或 Command 里直接改模型状态
Observer 是监听器，适合发通知或记日志，不适合改数据；Command 是命令行入口，和 HTTP 请求生命周期无关。两者都缺乏上下文隔离，容易引发竞态。
比如用户 A 提交内容，审核中时用户 B 又更新了同一条记录——如果 Observer 直接 $model->save()，会覆盖 B 的修改；而 Command 根本拿不到当前请求的 session 或 auth 信息，无法做权限校验。
真正该做的，是把审核回调路由到一个独立的 AuditCallbackController，用事务包裹状态更新，并记录操作人（即使为系统账号也要明确标记）。
最常被忽略的一点：回调 IP 必须白名单校验（如只接受腾讯云审核服务固定出口 IP），否则攻击者伪造回调可随意篡改 audit_status 字段。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
