订单日志核心字段需包含order_id、user_id、operator_type、status_before、status_after、remark、ip、created_at，用于精准追溯“谁在什么时候改了订单的哪个状态、为什么改”。
订单日志该记录什么字段才够用
订单日志不是越全越好，而是要能回答「谁在什么时候改了订单的哪个状态、为什么改」。ThinkPHP 本身不提供订单日志模块，得自己设计表和写入逻辑。核心字段至少包括：order_id、user_id（操作人，可能是用户或后台管理员）、status_before 和 status_after、remark（如“用户取消”“支付超时关闭”）、ip、created_at。别漏掉 operator_type 字段，用来区分是 user、admin 还是 system（比如定时任务自动关单）。
用模型事件还是手动调用 Log::write()
别用 Log::write() 写订单日志——它只适合调试信息，没有结构化字段，查起来费劲。正确做法是在订单模型（如 app\model\Order）里监听状态变更，用数据库写入。ThinkPHP 6+ 支持模型事件，推荐在 afterUpdate 里判断 $this->status 是否变化：
protected function afterUpdate()
{
$origin = $this->origin('status');
if ($origin !== $this->status) {
\app\model\OrderLog::create([
'order_id' => $this->id,
'user_id' => $this->operator_id ?: 0,
'operator_type' => $this->operator_type ?: 'system',
'status_before' => $origin,
'status_after' => $this->status,
'remark' => $this->remark ?: '',
'ip' => request()->ip(),
]);
}
}注意：必须提前把 operator_id 和 operator_type 赋值给模型实例，否则拿不到上下文；remark 建议由业务层传入，不要在模型里硬编码。
怎么避免高并发下单时日志写入失败
订单状态频繁变更（比如支付回调 + 用户取消同时到达），可能触发多次 afterUpdate，但日志表主键或唯一索引没设好，就会报 SQLSTATE[23000]: Integrity constraint violation。解决方案有三个：
立即学习“PHP免费学习笔记（深入）”；
- 日志表主键用自增
id，不依赖业务字段做唯一约束 - 在写入前加一层简单判断：用
Db::table('order_log')->where('order_id', $orderId)->count()控制单订单最多写 5 条日志，防刷 - 关键场景（如支付回调）改用事务：把订单更新和日志插入包进同一个
Db::transaction()，避免写一半失败
日志查询慢？加索引和分表时机
订单日志表增长极快，一个月就几十万条。不做优化，SELECT * FROM order_log WHERE order_id = ? 就会变慢。必须建联合索引：INDEX idx_order_time (order_id, created_at)。如果单表超 200 万行，别硬扛，按月分表，表名用 order_log_202406 这种格式，查的时候根据时间动态选表——ThinkPHP 的 Db::name() 支持变量传入表名，别写死。
真正容易被忽略的是：日志里的 remark 字段别用 TEXT 类型存大段 JSON，它会拖慢所有查询。只存关键动作描述，详情放 Redis 或单独的详情表里。
