17370845950

必须在订单日志中显式固化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":"2025-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 参数可能被篡改。

• 订单创建时：从用户 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 枚举。