php订单日志怎么在laravel写_php框架laravel写订单日志方法【方法】

订单日志应异步写入独立结构化数据库表,通过队列处理避免阻塞主事务;监听模型updated事件捕获真实状态变更;data字段需包含operator_id、ip、previous、current、source等上下文;务必建立order_id、event+created_at等关键索引以保障查询性能。

订单日志该写到哪里:数据库 vs 文件 vs 队列

直接往数据库表里 insert 日志,看似简单,但高并发下单时容易拖慢主事务。Laravel 默认的 Log 门面写文件(如 storage/logs/laravel.log)又难检索、无结构、不带订单上下文。

更合理的做法是:用独立数据表存结构化日志,并通过队列异步写入。这样既保证主流程不卡顿,又能按 order_idstatuscreated_at 快速查。

  • 建表迁移示例:
    php artisan make:migration create_order_logs_table
    ,表中至少包含 order_id(索引)、event(如 "paid""shipped")、datajson 类型,存变动字段、操作人、IP 等)
  • 不要在控制器或模型的 save() 方法里同步 DB::insert() —— 这会把日志错误拖垮订单创建
  • dispatch(new LogOrderEvent($order, 'created', $context)) 推进队列,Job 内再持久化

怎么记录关键状态变更:监听模型事件比手动写更可靠

订单状态不是只在“支付成功”时变,还可能被客服改、被超时任务关、被退款回调触发。硬编码日志调用极易漏场景。

Laravel 模型事件(updatingupdatedsaved)配合守卫逻辑,能自动捕获所有变更点:

  • App\Models\Order 中定义 protected $dispatchesEvents = ['updated' => OrderUpdated::class]
  • OrderUpdated 事件类里判断 $event->getOriginal('status') !== $event->status,只对真实变更写日志
  • 避免重复日志:不要监听 savingcreating —— 它们发生在事务提交前,若后续回滚,日志就失真

日志内容要带什么字段:别只记“做了什么”,要记“谁在什么时候为什么做”

光写 "order #123 status changed to shipped" 没用。排查问题时需要还原现场。

建议 data 字段固定存这些键:

  • operator_id:当前操作人 ID(从 Auth::id() 或请求头取;后台操作必须有,接口回调可设为 null"system"
  • iprequest()->ip(),非回调场景必填
  • previouscurrent:状态/金额/物流单号等关键字段变更前后值,方便 diff
  • source:标识来源,如 "wechat_payment_callback""admin_panel""cron_timeout_job"

示例写入结构:

["operator_id" => 42, "ip" => "192.168.1.100", "previous" => ["status" => "pending"], "current" => ["status" => "paid"], "source" => "alipay_callback"]

查日志时总卡死:索引和查询方式得提前设计好

线上跑三个月后,order_logs 表几十万行,where order_id = ? 还快,但 where event = 'refunded' and created_at > ? 就慢——因为缺联合索引。

必须加的索引:

  • order_id 单列索引(查单个订单全生命周期)
  • event + created_at 联合索引(查某类事件近期分布)
  • 如果常按操作人查,加 operator_id 索引(但注意 NULL 值不进 B-Tree 索引,回调日志里设 "system" 比留空好)

别用 LIKE '%shipped%'data 字段——JSON 字段应走 -> 操作符,例如:

whereJsonContains('data->source', 'admin_panel')
,并给 data 字段加生成列+索引(MySQL 5.7+ 支持)

实际最难的不是写日志,是定义清楚哪些变更算“值得记”。比如地址微调、备注修改要不要进日志?这得和产品、客服对齐,而不是由开发拍脑袋决定。