请求日志该核对哪些条件才能用于排查？

请求日志能帮助排查接口问题，但使用前要确认记录是否完整、来源是否清楚，以及是否包含敏感信息。先核对日志对应的系统、环境和时间范围，再查看请求与响应之间是否有可用的关联标识。若系统没有统一编号，可结合时间、接口路径和自有任务编号缩小范围；不能只凭时间接近，就认定两条记录来自同一次请求。 接下来检查字段能否回答当前问题。排查失败原因时，通常要看请求时间、接口路

请求日志能帮助排查接口问题，但使用前要确认记录是否完整、来源是否清楚，以及是否包含敏感信息。先核对日志对应的系统、环境和时间范围，再查看请求与响应之间是否有可用的关联标识。若系统没有统一编号，可结合时间、接口路径和自有任务编号缩小范围；不能只凭时间接近，就认定两条记录来自同一次请求。

接下来检查字段能否回答当前问题。排查失败原因时，通常要看请求时间、接口路径、响应状态和错误信息；比较输入与输出时，还要确认日志是否保留了必要摘要。工具和自建系统的记录能力各不相同，字段缺失时应说明判断受到限制，不能把空白当作请求没有发生。任务编号和内容摘要可用于自有系统识别重复入库，但摘要不是完整请求，也不能单独证明处理结果。

还要确认数据安全边界：日志可能包含提示词、用户内容、个人信息或凭证，使用前应核对访问权限、保存位置和保留范围，并按需隐藏敏感字段。密钥只保存在服务端或受保护的本机配置中，不应写入网页、文章或日志。排查时也不要为补充上下文而复制密钥。

请求超时不能直接证明它未处理或未计费。先检查已有响应、任务状态和关联记录，再决定是否重试；无法确认时，保留原请求的识别信息，避免重复提交造成重复处理。日志只能提供线索，模型输出也不等于事实核验。判断答案是否准确，还需另行核对可靠资料。这些做法适用于有权查看的自有系统；第三方工具的字段、留存方式和状态含义，应以其实际说明为准。