批量导入接口怎么判断文章已存在，重复执行会不会写两遍
调用文档内容导入接口做批量导入时，怎么判断文章已存在、重复执行会不会写入两遍？AnQiCMS 提供 /api/import/archive 文档内容导入接口，支持按标题查询文章是否已存在。幂等的做法就是把”先查后写”固化为调用顺序：每个标题先查存在性，已存在的跳过或走更新分支，确认不存在再写入。按这个顺序，重复执行不会把同一篇写两遍。
先查后写的顺序
一次导入循环里对每篇文章做两步。第一步，拿标题调用接口的存在性查询，得到”已存在/不存在”的判定；第二步，不存在的走创建，已存在的按策略选择跳过、改名再建或转入更新流程。别小看这个顺序，直接盲写的脚本在中断重跑时最容易产出同题重复条目，事后清理比事前查询成本高得多。
按标题查重的边界
以标题为键有两类边界情况要提前定规则：
- 源数据里本来就有同题文章（不同栏目同名），需要加栏目或日期后缀区分，否则第二条永远被判为已存在而跳过；
- 改版中同题更新内容，是”覆盖更新”还是”新建一篇”，必须按业务定一种并写进脚本，不能靠执行人临场判断。
查询判重只解决”写没写过”，不解决”该不该更新”，后者是策略问题。
断点续跑怎么记录游标
上千篇内容一次跑不完，中断后要能接着搬。做法是在本地维护游标：每完成一条，把标题和处理结果（创建/跳过/失败）追加写入日志文件；重跑时先读游标，日志里已完成的条目直接跳过，再配合按标题查询兜底。两层保险的意义在于：本地游标快，接口查询准，游标文件丢失或换机器时，按标题查存在性仍能保证不重复写入。
高频调用先限哪一端
批量脚本提速时容易压垮写入。AnQiCMS 接口调用的高频能力集中在文档列表与详情、分类与标签、图片上传、留言评论等内容面，其中读取类调用可以适度并发，而 import/archive 这类写入端点应控制节奏：单并发或低并发顺序跑，失败重试设退避间隔。先限写入端，比两端同时放开再收拾重复数据划算得多。具体参数与鉴权方式在站内的接口文档分类下可以查到，按文档口径调用。
导入结果怎么核对
跑完不等于导完，收尾核对三份账：
- 条目数——导入成功数加跳过数加失败数，应等于源清单总数；
- 状态——抽查若干条目在后台的实际状态（正式文档、草稿还是待发布），和脚本预期一致；
- 内容——随机抽几篇核对标题、分类、标签与自定义字段是否完整，图片类内容确认配图可访问。
失败清单单独留存，修复原因后只重跑失败部分；全程配合批量导入（ZIP 压缩包与 Excel 表格适合一次性建库，接口适合程序化续跑）按数据形态选通道。
常见问题
接口返回已存在，但我在后台找不到？ 先按标题精确搜索并检查回收站，删除过的条目仍占用标题判定；确认要重建时先彻底清理再导入。
能不能并发跑多个导入进程？ 不建议，写入端并发是重复条目和锁竞争的主要来源；要提速优先把查询与准备阶段（读文件、清洗数据）并行，写入保持单流。
中断后游标文件损坏了怎么办？ 删掉游标从头重跑即可，按标题查存在性会兜住已写入的条目，最坏情况是多花一轮查询时间，不会产生重复内容。