历史文章上千篇要迁到新站，压缩包和表格批量导入怎么配合用

上千篇历史文章迁到新站，建议两条通道配合使用：带图片等文件资源的存量内容走 ZIP 压缩包批量导入，字段规整、以纯文本为主的条目走 Excel 表格批量导入；导入前用文档导入接口按标题查询是否已存在，防止同一篇内容重复入库；导入过程分批执行，删除的正式文档进回收站而不是物理删除，出错可以回退。

两条通道各适合什么数据

判断依据是”内容里有没有文件”。有文件的走压缩包，没有文件的走表格，这条分工能避免把大量图片转成外链再手工补传。

迁移前先整理的三件事

第一是标题规范化。迁移最常见的事故不是导入失败，而是同一篇文章被导进两次。先按标题做一次归并，把重复稿、旧版与终版收敛成一条。

第二是分类映射。旧系统的栏目与新站的内容模型不是一一对应，先写清映射表，把落不进任何分类的内容单独列出人工决定，不要让它落到默认分类里堆积。

第三是字段对齐。表格通道要求标题、正文、分类、标签、发布时间等列结构稳定；旧数据里的空值、异常日期与富文本残留要先清理，否则抽查时很难判断是导入问题还是源数据问题。

先查再传：避免重复入库

批量导入接口（文档导入通道 /api/import/archive）支持按标题查询文档是否已经存在，用途就落在这里：每批上传前先查一次，已存在的条目跳过或走更新，不要靠人工记录”这批传过没有”。上千篇的规模下，中断与重传几乎必然发生，可重复执行而不产生脏数据是迁移脚本的基本要求。

分批切割的建议规模是单批几百篇，按分类或时间段切。批太小会拉长整体时间，批太大则出错时定位范围过宽。

导入后的抽查与回退

每批导入完成后先抽查再放大下一批，抽查项包括：

• 数量核对：本批计划条数与实际入库条数是否一致。
• 状态核对：批量导入的文档按预期状态入库，需要预览确认的用草稿状态带预览参数检查，确认无误再转正式文档。
• 资源核对：图片与附件是否可以正常访问，有没有路径失效。
• 结构核对：分类、标签与自定义字段是否落在正确位置。

处理错误时，删除正式文档会移入回收站而不是物理删除，误删可直接恢复；这层兜底让”先导进来看看”的策略风险可控。但要注意回收站不承担版本管理，改错了内容仍需从源数据重推，所以源文件的版本保留到迁移验收通过为止。

常见问题

问：能不能一次性把上千篇全打包传上去？ 答：不建议。单批过大时失败定位困难，一旦中途出错，难以判断哪些条目已入库；分批加逐批抽查在总耗时上往往更省。

问：正文里残留的旧站内链要不要先处理？ 答：要。迁移时顺手做一轮链接改写，把旧站路径指向新站地址，比上线后再用全站替换批量改更省成本，也能避免残留链接指向已失效地址。

问：旧站文章带评论和用户数据怎么办？ 答：这两类通常不在文档导入通道的范围内，建议保留旧站只读，或单独走数据库迁移，不要混进内容迁移的批次里。