预售订单状态变更必须统一调用logOrderStatusChange()记录日志，强制入参$order_id、$from_status、$to_status，自动采集URI、操作者、IP及时间，输出JSON行式日志；禁用fopen写文件，改用error_log()或syslog；数据库status_log表须新增trigger_event和source字段；所有日志order_id一律使用主订单号，与支付回调对齐。
预售订单状态变更时必须调用 logOrderStatusChange() 记录日志
预售订单和普通订单的核心差异在于状态流转更复杂（比如“待支付定金”→“定金已付”→“尾款待付”→“尾款已付”→“已发货”），不统一入口记录，极易漏日志或写错状态来源。必须强制所有状态更新走同一个日志写入函数，避免散落在 updateOrderStatus()、payDeposit()、payBalance() 等多个方法里手写 file_put_contents() 或直接插库。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 该函数接收三个必填参数：
$order_id（订单号）、$from_status（变更前状态码，如'deposit_pending'）、$to_status（变更后状态码，如'deposit_paid'） - 自动记录
$_SERVER['REQUEST_URI']和触发操作的$_SESSION['admin_id']或$user_id，便于追溯是后台改的还是用户支付触发的 - 日志内容格式固定为 JSON 行式（每行一个 JSON 对象），方便后续用
jq或日志系统解析：{"order_id":"SO20240517001","from":"deposit_pending","to":"deposit_paid","ip":"192.168.1.100","operator":123,"time":"2024-05-17 14:22:05"}
不要直接写文件，用 error_log() + 自定义 syslog 设施替代 fopen()
很多老项目用 fopen('logs/preorder.log', 'a') 追加写日志，但并发高时容易出现日志错位、写入失败不报错、权限被覆盖等问题。PHP 的 error_log() 在配置了 error_log = /var/log/php-preorder.log 且配合 log_errors = On 后，底层由系统调度，更稳定。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
php.ini中单独配一条日志路径：error_log = /var/log/php-preorder.log，并确保 PHP 进程有写权限 - 调用时传入
ERROR_LOG类型，并拼接结构化字符串：error_log(json_encode([ 'order_id' => $order_id, 'status_change' => "$from → $to", 'time' => date('Y-m-d H:i:s') ]), ERROR_LOG); - 如果用的是 Docker 或云环境，优先对接系统
syslog：用openlog('preorder', LOG_PID, LOG_LOCAL0)+syslog(LOG_INFO, ...)，这样能进集中日志平台（如 Loki / ELK）
status_log 数据表字段设计要包含 trigger_event 和 source
只存 order_id、old_status、new_status、created_at 四个字段，查问题时根本分不清是用户点击“支付尾款”按钮触发的，还是定时任务自动升单触发的，还是客服后台手动修改的。必须明确区分动作来源。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 数据库表至少加两列：
trigger_event（枚举值：'user_deposit_pay'、'user_balance_pay'、'auto_upgrade_to_normal'、'admin_force_update'）、source（字符串，如'web'、'app_v3.2'、'cron_job:upgrade_preorder'） - 插入语句必须显式赋值，禁止用
DEFAULT或留空：INSERT INTO status_log (order_id, old_status, new_status, trigger_event, source, created_at) VALUES (?, ?, ?, ?, ?, NOW())
- 查询时按
trigger_event聚合，能快速发现异常模式——比如某天突然大量'auto_upgrade_to_normal'但没对应订单履约，说明定时任务逻辑有误
预售订单日志必须和支付网关回调日志对齐时间戳和订单号
支付宝/微信回调通知里带的 out_trade_no 是预售订单号（如 SO20240517001），但有些开发把日志里的 order_id 写成子订单号（如 SO20240517001_D 定金单、SO20240517001_B 尾款单），导致无法和支付日志关联，排查支付成功但状态没变时无从下手。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有日志中
order_id字段一律使用主订单号（即用户看到的那个SO20240517001），子订单号仅用于支付下单接口，不落状态日志 - 在回调处理入口第一行就记录原始请求：
error_log('[WX_CALLBACK] ' . file_get_contents('php://input'), ERROR_LOG);，确保时间戳和主订单号可比对 - 写日志前校验回调签名和订单存在性，失败也记日志（
"wx_callback_failed: invalid sign for SO20240517001"），否则静默丢弃会导致“明明回调了但没日志”的假象
order_id、trigger_event、timestamp 必须能串成一条可信链。 
