批量导入前先按标题查一次存在性，中断的批次怎么续传

批量导入前先按标题查一次存在性，中断的批次怎么续传，正确顺序是「先取清单、再比标题、只补缺口」。AnQiCMS 提供的文档内容导入接口 /api/import/archive 支持按标题查询文档是否已存在，续传要围绕这个查询动作重建待发列表，而不是把原文件从头再跑一遍。

导入接口的查询动作做什么

import 与 archive 两个动作分工不同：archive 负责把整包内容写进文档库，import 侧的查询负责回答「这篇标题在不在」。批量场景里后者比前者更关键，因为一次几千条的导入，中断点几乎不可能落在整篇的边界上，通常是跑到某条时网络或进程断了。

续传第一步是拿已完成的清单。对源文件里每一个标题发起一次存在性查询，返回已存在的条目直接跳过，返回不存在的才进入第二批提交。这样即使上一批在中间断掉，也不会出现同标题重复入库。

批量导入支持 ZIP 压缩包和 Excel 表格两种方式，续传时不能混用。压缩包入口带的是文档正文与配图这类文件结构，一个包里的目录层级会被读成文档归属；表格入口带的是一行一篇的字段映射，标题、分类、标签这些列要提前对齐。

混用会带来的麻烦不是报错，而是静默错位：同一批内容用表格入口续传时，正文里的附件路径可能没有被带进去。所以上一批用哪种入口，续传就必须用同一种，接口文档里对两种入口的字段说明要留在手边核对。

按这个顺序走：

先停掉原任务，避免两个批次同时写同一个分类。再把源文件的标题列表导出，逐条走一次按标题查询，把结果分成「已入库」和「未入库」两组。第三组是可疑项，也就是标题存在但正文长度明显不对的条目，这类要单独人工看，不要直接覆盖。

只把未入库那组重新提交。提交时按 API 调用频率做节流，小批量分批发送比一次性全推更容易定位断点，万一中断，日志里能直接看到最后成功的那条。

同标题重复入库时，处理方式是删掉多余的那份而不是改标题。删除正式文档在 AnQiCMS 里是移入回收站，不是物理删除，所以清理动作可回退：先确认保留的那份内容完整，再把重复项移进回收站，观察一段时间后才做彻底清理。

批量导入前那次「按标题查存在性」就是为了把这个清理环节省掉。查询动作的开销远小于事后逐条比对标题的成本，尤其在同一个站点反复跑同一份源文件时。

会。按标题查询按字面匹配，多一个空格或全半角标点不同都会判成不存在，续传前先把标题做一轮规范化再比对。

不需要。ZIP 包本身没有状态，重新组包只增加出错面，按标题查询筛出的缺失清单用原包续传即可。

取决于单条写入与查询的往返次数，没有固定值。稳妥做法是先跑一小批计时，再按线性关系排后面的批次，并把时间因子设在低峰时段。