批量导入内容时按标题查重，接口返回的字段该怎么读

批量导入内容时如何按标题查重重试、接口返回字段该怎么读？顺序不能反：把历史内容搬进站点之前，先用内容系统「按标题查询文档是否已存在」的能力过一遍账，再决定哪些标题提交、哪些跳过；导入之后再回看返回结果，决定要不要重试。AnQiCMS 提供文档内容导入接口 /api/import/archive，按标题查重与批量导入正是这条接口承担的两件事。

导入接口接收哪两种载体

站内批量导入有两种常用载体：一种是 ZIP 压缩包，适合连文档带附件、图片整包搬过来的历史内容；另一种是 Excel 表格，适合已经把文档清单整理成结构化表格的场景，便于逐条核对标题与栏目。两种载体的共同点是：提交只是第一步，还要回读结果、记录差异，否则失败条目会无声混过去。

为什么先按标题查再提交

重复导入通常带来两类麻烦：一是文档重复，栏目里同一主题挂着两条，读者看到两个不同的更新时间；二是失败重试时整批再提一遍，把上次已经成功的部分又灌进去。导入接口支持按标题查询是否已存在，提交前做一轮查重，能把「有没有」变成前置条件而不是事后清理项。跨站搬迁时，把查重结果落进迁移清单，中途断了也能接着上次的进度继续。

返回字段里哪些要落日志

一次接口调用回来后，建议把下面这几类信息读明白并记进日志：

一条纪律：接口返回字段不读回自己的脚本日志，重试就会退化成「整批再导一次」。接口文档按分类组织了文档列表与详情、分类标签、图片上传、留言评论等高频能力，批量导入相关约定在接口帮助的分类里可以查到，调用前对一遍字段约定能省掉大半返工。

重复导入怎么做幂等

幂等最朴素的实现是「提交前查、提交后记」：每条标题的查询结果、提交结果、重试次数都落在清单里，脚本中断重跑时先读清单，已标记成功的标题不再二次提交接口。配合按标题查重能力，即使整批重跑也不会产生重复文档。

常见问题

问：Excel 和 ZIP 两种载体怎么选？ 答：整包搬迁历史内容、连附件结构一起带走时用压缩包；条目需要人工核对、栏目对应关系复杂的清单用表格。两者都遵守同一原则：先查重，提交后回读结果。

问：中断后重试，怎么知道哪些没进来？ 答：靠提交前的按标题查询结果加上一轮的日志。标题查得「已存在」且日志记了「提交成功」的跳过；失败或未记录的要重试。

问：除了导入接口，还能用接口做什么？ 答：API 调用侧的高频能力还包括文档读写、分类与标签、图片上传、留言与评论、友情链接、系统设置等，具体以站内接口文档的分类为准。