API接口调试：按顺序排查并记录关键信息

接口调用失败时，先别急着改代码或重复发送请求。按顺序记录现象、检查请求，再缩小排查范围。不同服务的字段和错误规则可能不同，具体以对应接口说明为准。 第一步，确认请求发往预期的地址和环境，再核对请求方法、路径及必要的请求头。若说明提供了示例，可以逐项比较；但不要把示例中的密钥复制到公开页面或代码仓库。密钥只应保存在服务端或受保护的本机配置中，也不要写入请求日

接口调用失败时，先别急着改代码或重复发送请求。按顺序记录现象、检查请求，再缩小排查范围。不同服务的字段和错误规则可能不同，具体以对应接口说明为准。

第一步，确认请求发往预期的地址和环境，再核对请求方法、路径及必要的请求头。若说明提供了示例，可以逐项比较；但不要把示例中的密钥复制到公开页面或代码仓库。密钥只应保存在服务端或受保护的本机配置中，也不要写入请求日志、文章正文或截图。

第二步，检查请求体：数据格式是否有效，字段名称、类型和必填项是否符合接口说明。涉及编码或换行时，也要留意实际发送的内容。调试记录可以保留脱敏后的请求结构和必要字段摘要，但应移除密钥、个人资料等敏感内容。

第三步，查看响应状态、错误信息和请求时间，并保存有助于定位问题的响应摘要。状态信息只是线索，需结合接口说明判断。请求超时不能证明服务端没有处理，也不能证明没有产生费用。先核对是否已有响应、任务结果或记录，再决定是否重试，以免重复创建任务。

如果系统支持任务编号，可保存编号和内容摘要，用于在自有系统中识别重复入库；这不代表所有接口都有相同机制。模型生成的内容还需另行核验事实，成功响应不等于内容准确。

最后，把可复现的请求条件、脱敏后的响应、发生时间和已尝试步骤整理在一起，便于继续排查或让他人按相同条件复现。如果问题仍未解决，再依据服务方说明联系支持，并避免公开敏感日志。