支付日志可能包含客户资料、交易标识、请求参数和认证信息，不适合作为普通公开附件。应保留定位问题所需的时间线与错误上下文，删除或遮盖不必要敏感内容，并通过受控渠道交给明确接收方。
先复制原件到受控档案
不要直接覆盖唯一原始日志，另存用于共享的副本。记录问题时间、订单或事件的内部关联及日志来源，确认时区一致。需要保存多久和谁可访问应按业务及适用要求确定，不在普通任务里长期存放完整支付资料。
按字段用途决定处理
认证头、API密钥、签名秘密及完整支付敏感信息不应公开；邮箱、地址、电话和姓名按必要程度脱敏。交易与事件标识可保留可关联的处理方式，但要考虑接收方是否确有需要。不能只遮住客户姓名却留下完整URL中的令牌。
保护足够的故障上下文
保留请求发生顺序、响应状态、错误类型、插件版本和已确认环境，使技术支持能理解问题。脱敏副本中同一个对象应使用稳定代号，避免把所有订单都改成相同字串而失去关联。不要为了“完整”把数据库或全部站点日志一起发送。
检查真实附件和接收范围
分享前再次读取最终文件，搜索常见密钥标记和个人字段，确认不是误传原件。记录接收对象、渠道及文件名，发送成功与技术方已阅读分别确认。故障解决后按约定处理临时副本，不把日志放到可索引网站或案例文章中。
关键区别
原始日志：用于受控溯源；不能随意公开覆盖。
共享副本：保留必要诊断信息；稳定代号便于关联。
凭据秘密：可造成账户风险；不得随附件泄露。
怎样确认处理到位
最终共享文件不含未授权秘密和个人资料，故障时间线仍可理解，接收人及渠道明确，原件安全保留，未将发送操作当成支持方已验收。
容易误判的边界
本篇不列举真实支付凭据，也不保证自动正则能发现全部敏感字段。应按当前网关日志结构和实际内容人工复核。
