必须在订单日志中显式固化payment_channel字段，于订单创建和支付回调双节点记录，使用统一枚举值并设为索引字段，禁止缩写、推导或嵌套存储。
订单日志里漏记 payment_channel，等于埋了个定时炸弹——后续对账、渠道效果分析、甚至风控排查都可能卡壳。必须在日志写入时就固化这个字段，不能靠事后补全或靠订单表反查。
日志结构里必须显式存 payment_channel 字段
别依赖“订单表里有，日志里不存也行”。订单状态会变，支付渠道却只在创建/支付那一刻确定。日志是不可变事实快照，payment_channel 必须作为独立字段写入，而不是塞进模糊的 remark 或 extra 里。
-
payment_channel值应来自支付请求源头（如前端传参、网关回调参数），不是从用户 ID 或订单类型推导 - 推荐固定枚举值：
alipay_app、wechat_jsapi、unionpay_h5、bank_transfer，避免用ali/wx这类缩写 - 若使用 JSON 日志格式，确保该字段是顶层键，不要嵌套多层，例如：
{"order_id":"ORD123","payment_channel":"alipay_app","status":"paid","created_at":"2024-06-15 10:22:33"}
在支付回调和订单创建两个关键节点都记录
只在回调里记？错。用户可能下单后放弃支付，或者支付成功但回调丢失。必须双保险：
- 订单创建时（
create_order接口）：只要用户选了支付方式，就立刻记一条status=created的日志，带payment_channel - 支付回调时（
notify接口）：无论成功失败，都追加日志，复用原payment_channel，不重新取值 - 两处日志用同一
log_type分类（如order_create/payment_notify），方便按渠道聚合查询
别用 $_POST 或 $_GET 直接取渠道值
用户可控参数不能直接入库或入日志。微信回调里 trade_type 是可信的，但前端提交的 channel 参数可能被篡改。
立即学习“PHP免费学习笔记（深入）”；
- 订单创建时：从用户 session 或登录态绑定的支付偏好取，或由后端根据业务规则决定（如企业客户强制走
bank_transfer） - 回调处理时：以支付网关返回的字段为准，比如支付宝用
service或pay_method，微信用trade_type，并做白名单校验 - 写日志前加校验：
if (!in_array($channel, ['alipay_app', 'wechat_jsapi', 'unionpay_h5'])) { log_error("invalid payment_channel: $channel"); }
查日志时用 payment_channel 做索引字段
如果日志存在 MySQL 或 Elasticsearch 中，别等要用时才发现查不动。提前把 payment_channel 设为索引字段：
- MySQL 表：给
payment_channel加普通索引，尤其当单日日志量 >10 万条时 - Elasticsearch：映射中设
"payment_channel": {"type": "keyword"}，不用text - 查某渠道失败率：
SELECT COUNT(*) FROM order_log WHERE payment_channel = 'wechat_jsapi' AND status = 'failed';
最常被忽略的是：日志里写了 payment_channel，但没统一命名规范，导致有的写 wxpay，有的写 wechat_pay，有的还带大小写混用。查的时候得先去 dedup，不如一开始就 enforce 枚举。
