批量导入文章该用哪种方式，接口和后台各管什么场景

批量导入文章该用哪种方式，取决于内容从哪来、由谁触发：人工整理好的一批稿件走后台批量导入，程序自动产出的归档走导入接口。AnQiCMS 两条路都留着，后台支持 ZIP 压缩包和 Excel 表格两种批量导入形式，接口侧提供文档内容导入接口 /api/import/archive，可以先按标题查询是否已存在再决定是否写入。选错的代价通常是重复文档和字段错位，而不是导入失败。

两条链路的分工边界

后台批量导入是「人在场」的操作：整理目录、打包、点导入、看结果，一次几百篇尚可处理，每天定时增量就不合适了。接口导入是「程序在场」的操作：调用方负责准备数据与重试，站点只负责接收与查重，适合内容工厂式流水线、跨系统同步、以及由脚本或 AI 工具面驱动的产稿。

判断标准很实在：同一批内容是否需要每次都人工确认。需要确认的走后台，只按规则运行的走接口。

后台批量导入的适用面

从旧系统导出数据，最常见的产物是一个内容压缩包加一张表格。这类一次性迁移用后台批量导入最省事：先在一个小分类里导 5 到 10 篇试手，确认标题、发布时间、分类归属与标签都对得上，再放大到整批。一次性迁移的量级大，导入前应确认备份可用，把数据（含静态文件）做一次备份，出问题能整站回退。

三种情况只适合走后台：源数据是人工整理的文档包；分类映射还没定死，需要边导边调；导入后立刻要人工抽查排版。

接口导入适合什么场景

程序化产稿必须走接口。典型场景是每天定时把外部编辑系统里的定稿推进来，或者由自动写作流程批量落稿。接口导入的关键动作是「先查后写」：调用 /api/import/archive 之前，先按标题查询该文档是否已存在，存在则跳过或更新，不存在才写入。少了这一步，同一篇稿件会在几天内被推成十几份重复文档，之后再靠回收站逐条清理。

调用方需要知道文档列表与详情、分类与标签这些能力，接口文档要在集成前读完；AnQiCMS 的公开 API 调用面覆盖文档列表/详情、分类与标签、图片上传、留言与评论、友情链接、系统设置等高频能力，把这些接口文档先过一遍，再决定导入接口放在流程的哪一步。

迁移前核对哪几项字段

导入失败的多数不是「导不进去」，而是「导进去不对」。动手前列一张字段核对表：

• 标题：是否带旧系统的栏目名前缀，是否重复。
• 分类：旧栏目如何映射到新分类，未映射的走默认分类还是直接拒收。
• 自定义字段：内容模型里的字段名是否一致。AnQiCMS 支持自定义内容模型与自定义字段，旧系统的扩展字段如果名称不匹配，导入后会空着，这部分要在模板里同步调整。
• 正文与图片：图片是否已在新站可访问，外链图片要不要先转存。
• 状态：导进来的草稿、待发布还是正式文档，是否要定时发布。

迁移后怎么验收

抽样比全量看更有效。按分类各抽几篇，核对标题、正文排版、图片、标签与摘要是否完整，再确认列表页与详情页能正常打开。旧链接的承接放在这一步一起做：老地址要么用 301 重定向指到新地址，要么用全站替换工具批量替换关键词或链接，别让导入完成等于上线完成。

删错的文档不要慌：删除正式文档是移入回收站而非物理删除，从回收站恢复即可，这给批量导入后的清理留了余地。

常见问题

旧系统只能导出 HTML 文件，走哪条路？ 打成一个 ZIP 压缩包走后台批量导入；包内目录结构保持一层，避免同名文件互相覆盖。

接口导入和后台批量导入能混用吗？ 可以。常见做法是历史内容用后台一次性导入，之后的增量交给接口按天推进。

导入后发现分类挂错了怎么办？ 小批量在后台逐条改，成批错挂先用全站替换处理链接与关键词，再按分类批量调整，改前先备份。

同一批内容重复导了两次怎么处理？ 以标题为准保留一份，其余删除进回收站，确认无误后再清空；下次由接口侧的按标题查询来拦住重复写入。