订单日志与支付日志职责分离、不可混用：前者记录“用户要买什么”，后者记录“钱有没有到账”，二者在生成时机、数据来源、字段结构、存储表、合规要求及排查目标上均完全不同。
订单日志和支付日志在电商系统中职责不同、生成时机不同、数据来源和用途也完全不同——不能混用，也不该共用同一张表或同一个日志通道。
订单日志记录“用户要买什么”，支付日志记录“钱有没有到账”
订单日志聚焦业务动作本身：谁、什么时候、下了哪几件商品、收货地址是什么、库存是否扣减成功、状态是否从 pending 变为 paid。它由订单创建、修改、取消等操作主动触发，通常写入 order_log 表或独立日志文件，内容含 order_id、user_id、status_before、status_after、operator 等字段。
支付日志则围绕资金流转：哪笔订单对应哪次支付请求、调用了哪个支付渠道（如 alipay 或 wxpay）、预支付 ID 是什么、回调通知是否收到、签名是否验签通过、最终 pay_status 是否更新为 success。它往往关联 pay_log 表，关键字段包括 log_id、order_id、pay_id、out_trade_no、notify_time、notify_content（原始回调体，需脱敏）。
- 订单日志可由前端提交或后台手动操作触发；支付日志只能由支付网关回调或支付接口调用后生成
- 订单状态变更可能不触发支付（比如用户下单后放弃支付）；而一次支付成功必须且只能影响一个订单的状态
- 支付日志中
out_trade_no通常是$order['order_sn'] . $log['log_id']拼接而成，确保幂等性；订单日志里没有这个字段
为什么不能把支付日志塞进订单日志里？
因为二者生命周期和排查目标完全错位：
立即学习“PHP免费学习笔记（深入）”；
- 当用户投诉“我明明付了钱，订单却没变已支付”，你要查的是支付回调是否到达、验签是否失败、
pay_log中is_notify是否为 1、pay_status是否更新——这些信息如果混在订单日志里，等于把“钱的轨迹”藏进“货的轨迹”，查起来像大海捞针 - 支付日志需要保留原始回调报文（
notify_content），而订单日志严禁记录敏感字段（如银行卡号、token），字段结构和脱敏策略天然冲突 - 第三方支付平台要求交易单号（
out_trade_no）全局唯一且不可复用；订单号（order_sn）可重复用于多次支付（如余额不足时换渠道重付），但支付日志 ID（log_id）必须每次新建
/* 示例：支付日志关键字段写法（非订单日志） */
$log_data = [
'log_id' => $db->insert_id(),
'order_id' => $order['order_id'],
'order_sn' => $order['order_sn'],
'pay_id' => $order['pay_id'],
'out_trade_no' => $order['order_sn'] . '_' . $db->insert_id(), // 注意拼接逻辑
'pay_code' => $payment['pay_code'],
'notify_time' => $_POST['notify_time'] ?? null,
'notify_content' => json_encode($_POST, JSON_UNESCAPED_UNICODE), // 原始回调，需后续脱敏处理
'created_at' => date('Y-m-d H:i:s')
];
$db->autoExecute($ecs->table('pay_log'), $log_data, 'INSERT');
日志存储建议：分通道、分级别、分保留周期
PHP 项目中推荐用 Monolog 按模块隔离日志输出，而不是靠人工拼字符串写文件：
- 订单操作走
orderchannel，级别设为INFO和WARNING，保留 30 天 - 支付相关（含回调、验签、状态更新）走
paymentchannel，ERROR级别必须邮件告警，DEBUG级别保留原始请求/响应（生产环境关闭） - 所有支付日志中的
notify_content、sign、private_key等字段，在写入前必须用unset()或正则脱敏，否则违反 PCI DSS 合规要求
最容易被忽略的一点是：支付日志的 log_id 必须在支付请求发起前就生成并落库（哪怕只是占个位），否则回调来临时找不到对应记录，就会导致“已付款但订单未更新”的静默失败——这比报错更危险。
