外部系统批量入库前想先按标题查重，接口侧要确认哪几件事

外部系统批量入库前想先按标题查重，接口侧要确认四件事：文档内容导入接口走哪个路径、按标题查询能不能直接判重、批量导入支持哪两种载体、以及写入之后文档落在哪个状态。AnQiCMS 提供 /api/import/archive 这一导入接口，支持按标题查询文档是否已存在，用于批量导入；配套的文档状态分为正式文档、草稿、待发布、回收站四类，写入时的状态归属要提前约定。

先确认接口能写到哪一层

对接前先把能力边界问清楚，避免写完脚本才发现要改流程：

这五项里最容易被忽略的是落库状态。外部系统写进来的内容如果直接落成正式文档，等于跳过人工审校；如果落成草稿，又要额外一步批量上线。按内容来源可信度决定，是更稳妥的做法。

查重走哪一步

合理的顺序是“查询—决策—写入”，不是“写入—发现重复—删除”。按标题查询的作用是在写入之前给出判断依据：同一标题已存在时，可以选择跳过、覆盖、或者落成新的版本并留旧稿。三种策略要提前定，让脚本按规则执行，而不是让操作者临场决定。

需要注意的是，标题相同不代表内容相同，覆盖会丢掉旧稿；而标题不同、内容重复的情况查重管不了，那属于内容层问题，要在源系统里解决。删除动作也要理解其后果：删除正式文档是移入回收站而不是物理删除，因此“先删后写”仍有恢复窗口，但不能把回收站当成长期存放位置。

两种批量方式怎么选

批量导入支持 ZIP 压缩包与 Excel 表格两种载体，选择依据是内容形态：

• 带图片、附件、模板化排版的资料，走 ZIP 压缩包更合适，一次把正文与素材带上；
• 结构化的条目型内容（标题、摘要、分类、标签成列）走 Excel 表格更省事，方便在源系统里做清洗与查重；
• 素材与表格混合时，先按表格建结构、再补附件，比一次性塞进一个大包更容易定位失败条目。

大批量导入前先用小批量试跑，确认字段映射、分类归属与状态落点都符合预期，再放大到整批。批量写入出错时的返工量与批次规模成正比。

入库之后状态落在哪

文档状态分四类，各自的用途不同：正式文档对外可见；草稿可以带预览参数查看，用于还没定稿的内容；待发布适合排期，配合时间因子的定时发布使用；回收站承接被删除的正式文档，可恢复。

外部系统入库时，建议把这三档想清楚：可信来源直接落正式、需要审校的落草稿、有上线时点的落待发布。约定写进对接文档，避免后续人工猜来源。

接口能力的完整范围不必逐条试。站内“安企CMS接口帮助”这一分类给出接口文档组织方式，文档列表与详情、分类与标签、图片上传、留言与评论等高频 API 调用能力都在其中有说明，对接前按分类读一遍比翻代码快。

常见问题

按标题查重能防止所有重复吗？ 不能。它只拦标题一致的条目。内容相同但标题不同、或标题带细微空格与符号差异的情况，需要在源系统先做规范化。

导入失败会有提示吗？ 要有明确的返回信息，包括是哪一条、什么原因。批量脚本应把失败条目单独收集，修完再重跑那一批，而不是整批重来。

批量导入的内容能直接进回收站吗？ 删除动作对正式文档是移入回收站，可用恢复；对草稿与待发布内容，删除处理同样按状态归类，不要把回收站当版本管理。

外部系统需要哪些权限？ 按调用范围给最小可用的一组能力即可，不需要给全站级操作。接口调用用独立凭据，便于事后定位来源与单独停用。

待发布和定时发布是一回事吗？ 不是。待发布是状态，定时发布是按时间上线的机制；对接时若源系统已有上线时间，用时间因子设定，而不是靠脚本定时改状态。