17370845950

PHP订单异常日志必须带order_id、request_id或trace_id等唯一上下文标识，统一在入口生成并透传，强制前缀拼接；重点记录资金、库存、状态机跃迁异常，含原始响应与快照；格式须ISO 8601、小写下划线字段、敏感脱敏；日志写入前需校验可写性。

PHP 订单异常日志不能只靠 error_log() 或简单 file_put_contents() 往文件里塞，否则查问题时根本分不清是哪个订单、哪个环节、哪次重试出的错。

订单日志必须带唯一上下文标识

没有 order_id、request_id 或 trace_id 的日志等于无效日志。PHP 本身不自动注入这些，得在入口（如控制器或服务层）统一生成并透传。

• 推荐用 uniqid('', true) 或 bin2hex(random_bytes(8)) 生成轻量级 trace_id
• 所有日志写入前，强制拼接 [trace_id:xxx][order_id:123456] 前缀，别依赖日志系统后期解析
• 避免在多个函数里重复生成 trace_id，用 static $trace_id ??= ... 或依赖注入容器传递

捕获订单关键路径的异常点

不是所有 try/catch 都值得记日志，重点盯住资金、库存、状态机跃迁这三类高风险操作。

• PayService::pay() 失败必须记录原始支付响应（含 http_status、body、headers），不能只记“支付失败”
• StockService::decrease() 抛出 StockNotEnoughException 时，要补上当前库存快照（SELECT stock, version FROM stock WHERE sku_id = ?）
• 订单状态从 pending → paid 失败，日志里必须包含旧状态、期望状态、数据库实际查到的状态值

日志格式要兼容 grep 和 ELK 检索

别用中文描述+空格分隔的“人话日志”，机器没法高效过滤。字段顺序和分隔符必须固定。

2025-05-22T14:23:18+08:00 [ERROR] [trace_id:abc123] [order_id:ORD789012] [service:PayService] [method:pay] [code:422] [msg:payment declined by gateway] [raw_response:{"err_code":"BALANCE_INSUFFICIENT"}]

• 时间必须用 ISO 8601（date('c')），带时区，别用 Y-m-d H:i:s
• 字段名全小写加下划线（trace_id 不是 traceId），方便 Logstash grok 解析
• 敏感字段如银行卡号、token 必须脱敏（substr($card, 0, 6) . '****' . substr($card, -4)）

不要把日志和监控混为一谈

日志解决“发生了什么”，监控解决“是否该报警”。订单异常日志本身不触发告警，但要确保日志能被 grep "status:failed" 或 Prometheus + Loki 的 {job="php-order"} |= "ERROR" | json | status == "failed" 精准命中。

• 避免在日志里写“稍后重试”，这种模糊表述无法触发自动化巡检
• 对超时类异常（如 cURL error 28: Operation timed out），额外记录 curl_getinfo($ch, CURLINFO_TOTAL_TIME) 耗时
• 异步队列消费失败时，日志里必须体现 attempt:3 和 max_attempts:3，否则分不清是首次失败还是重试耗尽

最常被忽略的是：日志写入失败本身。如果磁盘满、权限错、NFS 挂载断开，file_put_contents() 静默失败，订单异常就彻底消失了。务必在日志组件初始化时用 is_writable() + 小文件写入测试兜底。