订单日志必须记录的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":"202505..."}'，注意用 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 表，查起来慢，索引失效，运维备份都痛苦。

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 不稳定。