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 检索
别用中文描述+空格分隔的“人话日志”，机器没法高效过滤。字段顺序和分隔符必须固定。
立即学习“PHP免费学习笔记（深入）”；
2024-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() + 小文件写入测试兜底。
