支付系统日志设计，完整记录每一笔支付请求、回调、签名串
支付系统日志设计，完整记录每一笔支付请求、回调、签名串，是支付对账、问题追踪和风控审计的基础。
很多线上支付问题之所以难查，往往不是代码逻辑复杂，而是日志里缺少关键字段：漏记了请求时间、原始报文、回调内容、签名串或验签结果。
本文从运维和开发结合的角度，给出一个零基础也能照做的日志记录方案，包含落盘格式、字段清单、敏感信息处理和验证手段。
支付日志到底该记哪些字段
支付日志和普通业务日志不同，它需要能够还原一笔支付从发起、通知到结果确认的完整链路。
建议至少记录以下信息：
- 基本信息：订单号、商户订单号、支付渠道订单号、支付金额、币种、交易状态。
- 请求信息：发起支付的完整请求 URL、请求头关键字段、请求体（或签名串前的原始参数）、时间戳。
- 回调信息：支付渠道回调的原始报文、头部签名相关字段、收到回调的时间、处理结果。
- 签名串信息：参与签名的原始参数、签名算法、密钥版本、生成的签名串、验签结果。
- 服务信息：服务器 IP、应用节点、环境标识（如 test/prod），便于多节点排查。
如果使用结构化日志，推荐每行一个 JSON 对象，字段全部用英文命名，例如 order_no、channel_order_no、pay_amount、sign_str、verify_result。
这样后续用 grep、jq 或日志平台检索都比较方便。
请求和回调日志怎么落盘
在没有专门日志系统的情况下，推荐直接写本地文件，按天切分。
以 Java 的 logback 为例，可以用独立的 logger 输出到独立文件，避免和业务日志混在一起：
/data/logs/pay/pay-info.log
/data/logs/pay/pay-info-%d{yyyy-MM-dd}.log
90
UTF-8
%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n
关键点在于：支付日志必须包含接收原始请求的时间戳，以及日志写入延迟不能影响主流程。
建议用异步 appender，避免磁盘 I/O 拖慢支付接口。
对于 PHP 等环境，可以用自定义函数写 file_put_contents 追加，但要注意加文件锁，并控制单条日志大小。
生产环境更建议借助 Nginx access_log 记录回调请求的原始 body，不过修改配置前要确认反代软件支持读取请求体。
签名串和验签结果怎么处理
签名串通常涉及密钥，记录时不能直接暴露完整密钥，但需要记录签名串本身和验签状态。
比如微信支付、支付宝的回调，会携带签名参数，服务端会拿本地密钥重新计算然后比对。
日志里应该记录：
- 接收到的签名值（
sign或signature）； - 本地用于验签的原始参数串（不含密钥或对密钥做掩码）；
- 使用的签名算法（如 RSA2、HMAC-SHA256）；
- 验签成功或失败，失败时附上失败原因。
示例日志行：
{"ts":"2025-06-01 10:00:01","order_no":"20250601100001","channel":"alipay","event":"callback","sign":"abc123...","sign_type":"RSA2","verify_result":"failure","reason":"signature mismatch"}需要特别注意：签名串的明文记录如果包含敏感参数，应做脱敏处理，例如只保留手机号前三位后四位、银行卡号中间四位等。
不要为了排查方便把完整的身份证、卡号直接写进日志。
容易踩的坑和验证方法
很多支付日志“记了”但排查时没用，常见原因有三个：
- 只记了回调结果，没有记录原始请求报文，导致渠道返回异常数据时无法还原场景。
- 把签名串和密钥放在同一个日志文件，安全审计不通过。
- 日志切分和清理策略缺失，磁盘被撑满，支付服务直接宕机。
建议每次上线前做一次模拟验证：用测试单据发起一笔支付，然后到日志目录执行命令检查：
tail -n 50 /data/logs/pay/pay-info.log | jq .确认能看到完整的请求和回调记录，签名验签结果符合预期。
再手动删除一天的日志文件，观察切分策略是否正常生成新文件。
对于高频支付，还应该检查单行日志大小，避免因 request body 过大导致日志写入延迟。
支付系统日志设计不是一次写完就结束，重点是把“可追溯”做实：每一笔支付都能按照订单号串起请求、回调和签名串，遇到问题能直接定位到具体环节。
如果后续需要做数据分析或审计，还可以把本地日志同步到 Elasticsearch 等集中平台，但前提是源日志的字段完整、格式稳定。
