请求日志使用前：先核对适用范围与例外

请求日志能帮助排查接口问题，但不能单独说明请求是否成功、任务是否完成或费用如何变化。使用前先确认日志记录的是哪一环：客户端发出请求、服务端收到请求，还是系统保存处理结果。不同环节的记录回答的问题不同，不能互相替代。 用于排查调用失败时，先核对时间、任务编号、请求状态和已有结果，确认它们对应同一次操作。若要在自有系统中防止重复入库，可用任务编号和内容摘要辅助

请求日志能帮助排查接口问题，但不能单独说明请求是否成功、任务是否完成或费用如何变化。使用前先确认日志记录的是哪一环：客户端发出请求、服务端收到请求，还是系统保存处理结果。不同环节的记录回答的问题不同，不能互相替代。

用于排查调用失败时，先核对时间、任务编号、请求状态和已有结果，确认它们对应同一次操作。若要在自有系统中防止重复入库，可用任务编号和内容摘要辅助识别重复记录。前提是系统本身有相应记录和业务流程；这不代表所有接口都有相同字段或内置去重功能。

遇到超时，应先查已有结果，再决定是否重试。网络中断或等待超时，只能说明当前环节没有及时得到响应，不能据此断定请求未被处理或未计费。若系统可以查询任务状态，先按已有编号核对；若不能查询，则结合本地记录和业务影响谨慎处理，避免盲目重复提交。具体重试方式以接口说明和自有系统设计为准。

还要区分排障信息与敏感信息。日志可记录所需的状态、时间和脱敏后的摘要；密钥只能保存在服务端或受保护的本机配置中，不能写入网页、正文或日志。记录范围应符合排障需要，避免长期留存不必要的用户数据。

日志提供的是线索，不是事实核验。模型生成的内容仍需另行核对，请求状态也不能证明回答正确。确认日志来源、记录环节、字段含义及任务对应关系后，才能判断它适用于哪类排查；条件不全时，结论应限于实际观察到的现象。