订单日志必须记录的7个核心字段是order_id、log_type、status_before、status_after、operator、ip、created_at、trace_id；缺任意一个都将导致问题排查困难，如用户投诉或财务对账异常。
订单日志必须记录的 7 个核心字段
不记全这 7 个字段，后续查问题基本靠猜。尤其当用户投诉“没收到货但系统显示已发货”或财务对不上账时，缺任意一个都可能卡住排查链路。
-
order_id：必须是业务主键，不能用数据库自增 ID 替代（分布式系统下易冲突） -
log_type：枚举值，如'create'、'pay_success'、'ship_out'、'refund_apply'，避免用模糊描述如'status_change' -
status_before和status_after：状态变更类日志必填，类型要统一（比如都用字符串'pending'/'paid'，别混用数字和字符串） -
operator：操作人标识，优先用user_id或admin_id，不用昵称或邮箱（脱敏/查重/关联权限都依赖它） -
ip：客户端真实 IP（注意 Nginx 要配proxy_set_header X-Real-IP $remote_addr;，否则记到的是负载均衡 IP） -
created_at：用date('Y-m-d H:i:s')或date('c')，别用time()时间戳——日志分析工具（如 ELK）解析字符串时间比整数更稳 -
trace_id：全链路追踪 ID，PHP 可通过$_SERVER['HTTP_X_TRACE_ID']获取（需上游透传），没有就用uniqid('', true)生成
哪些字段看起来可选但实际高频使用
这些字段单次日志里不强制，但漏掉三个以上，三个月后查一次跨系统异常就会想重写日志模块。
-
source：调用来源，如'app_v3.2.1'、'wechat_mini_program'、'internal_api'，区分是用户主动操作还是后台定时任务触发 -
extra_data：JSON 字符串字段，存动态内容，比如支付回调里记'{"pay_channel":"alipay","trade_no":"202405..."}'，注意用json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES)防乱码和转义爆炸 -
error_code和error_message：仅在log_type为'pay_fail'或'notify_retry'时非空，但必须留空字段结构，别删掉——否则日志表字段不一致，SQL 查询会报错
PHP 写入日志时最容易踩的坑
不是代码写不对，而是环境/配置/习惯导致日志失效或难用。
- 用
file_put_contents()直接追加？并发高时会丢日志。改用fopen(..., 'a') + flock() + fwrite() + fclose()，或直接切到monolog+rotatingfilehandler - 日志路径写成相对路径如
'./logs/order.log'？CLI 模式下工作目录可能变，必须用绝对路径：__DIR__ . '/runtime/logs/order.log' - 把敏感信息如
card_no、id_card原样记进日志？违反 GDPR 和等保要求。统一过一遍mask_sensitive_data()函数，例如substr($card, 0, 4) . '****' . substr($card, -4) - 没加
mb_internal_encoding('UTF-8')就记中文？某些 PHP 版本下json_encode()会崩，日志里出现或直接空白
MySQL 日志表结构建议（非 EAV）
别为了“灵活”搞成 key/value 表，查起来慢，索引失效，运维备份都痛苦。
立即学习“PHP免费学习笔记（深入）”；
CREATE TABLE `order_log` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `order_id` varchar(32) NOT NULL COMMENT '业务订单号', `log_type` varchar(20) NOT NULL COMMENT '日志类型', `status_before` varchar(20) DEFAULT NULL, `status_after` varchar(20) NOT NULL, `operator` varchar(32) NOT NULL COMMENT '操作人ID', `ip` varchar(45) NOT NULL, `trace_id` varchar(64) DEFAULT NULL, `source` varchar(50) DEFAULT NULL, `extra_data` text COMMENT 'JSON格式扩展字段', `error_code` varchar(32) DEFAULT NULL, `error_message` varchar(512) DEFAULT NULL, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_order_id` (`order_id`), KEY `idx_trace_id` (`trace_id`), KEY `idx_created_at` (`created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
注意 extra_data 用 text 而非 json 类型——老版本 MySQL 不支持 JSON 函数，且部分 ORM（如 Laravel Eloquent）对 JSON 字段的自动 cast 不稳定。
