API请求日志异常时，按顺序排查记录与结果

请求日志出现缺项、重复或状态不明时，先别急着重发。日志反映的是系统实际记录的信息，不能单凭一条记录判断模型是否处理了请求。可以先界定异常，再核对请求、响应和业务入库情况。 第一步，选定一个具体例子，记录问题发生的大致时间、调用入口、业务任务编号，以及已有的请求标识和状态。先确认异常是单次出现，还是持续了一段时间。检查时只查看自己有权限的系统；密钥不要复制到

请求日志出现缺项、重复或状态不明时，先别急着重发。日志反映的是系统实际记录的信息，不能单凭一条记录判断模型是否处理了请求。可以先界定异常，再核对请求、响应和业务入库情况。

第一步，选定一个具体例子，记录问题发生的大致时间、调用入口、业务任务编号，以及已有的请求标识和状态。先确认异常是单次出现，还是持续了一段时间。检查时只查看自己有权限的系统；密钥不要复制到工单、网页或日志中，也要留意现有日志是否暴露凭据。

第二步，沿调用链核对记录。对照自有系统保存的请求、接口返回和后续处理记录，查看缺失环节及时间顺序。若系统保存了任务编号或内容摘要，可据此检查任务是否已处理或入库，避免把重复提交当成新任务。各系统记录的字段和保留方式不同，不能假设每个接口都有相同的日志能力。

第三步，区分超时与失败。超时只表示调用方未在预期时间内拿到结果，不能证明请求未处理，也不能据此判断是否计费。重试前先查已有响应、任务状态和业务数据；仍无法确认时，记录不确定之处，再按本地系统的恢复流程处理。日志中没有结果，也不足以证明服务端从未收到请求。

最后根据异常范围继续排查：多个调用都缺少相同记录时，检查共同的日志采集或写入环节；只有一个任务异常时，先核对该任务的输入、调用时间和后续处理。完成后补齐必要的状态记录，并确认密钥未进入日志。这套方法适用于能够查看自有调用和业务记录的场景。缺少服务端日志时，当前证据有限，仍需通过相应状态核查确认；模型输出本身也不等于事实核验。