博客写作软件：工具停服后哪些数据应该优先迁出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /86e128b07140.html
📄
博客写作软件：工具停服后哪些数据应该优先迁出
优先迁出的是无法从公开渠道重建、且直接决定后续发布与检索表现的原始资产：你亲手写下的正文源文件、图片与附件的原始文件、以及文章的稳定标识（标题、slug、发布时间、作者、分类与标签）。排版主题、插件配置和统计数字通常可以重建或重新采集，不必抢在停服前搬运。下面用一个假设情境把决策过程写清。
假设情境：一款博客写作软件宣布三个月后停服
假设你使用某款博客写作软件已两年，站内有约两百篇文章，工具同时保存草稿、已发布正文、图片和一套自定义排版主题。停服公告只说服务将关闭，未说明导出格式是否完整。此时不要先问“能导出多少”，而要问“哪些数据一旦丢失就无法用其他方式补回”。按这个标准，正文源文件和媒体原图属于不可再生资产，主题样式和阅读量属于可重建资产，迁移顺序由此确定。
第一优先级：正文源文件与稳定标识
正文是唯一无法从搜索引擎或缓存中完整还原的内容。缓存和快照可能保留部分文字，但会丢失段落结构、内链、代码块和更新后的版本，不能作为迁移来源。
- 导出时优先选择保留语义结构的格式，例如带标题层级和列表标记的 Markdown 或结构化 HTML，而不是纯文本或 PDF。纯文本会丢掉链接和层级，PDF 难以再次编辑。
- 同时记录每篇文章的标题、slug、发布时间、作者、分类和标签。slug 是旧链接能否继续指向同一内容的关键，迁移后若 slug 变化，需要为旧地址设置跳转。
- 草稿与已发布内容分开导出。草稿往往没有外部链接，迁移优先级低于已发布正文，但其中可能包含未发布的原创内容，仍应保留一份。
实际动作：先导出全部已发布正文并抽查三篇，确认标题层级、内链和代码块是否完整。如果抽查发现结构丢失，下一步应改用另一种导出格式重试，而不是直接进入新平台的排版环节。
第二优先级：图片与附件的原始文件
正文里的图片若只导出为带外链的引用，停服后链接会失效，文章将出现大量空图。需要把图片和附件按原始分辨率下载到本地，并保留文件名与文章之间的对应关系。
- 区分原图与压缩图。部分工具会为页面展示生成压缩版本，迁移时应尽量取原图，否则后续放大或改版会明显失真。
- 记录图片在正文中的位置。仅有一堆图片文件而不清楚哪张属于哪篇文章，重新插入的工作量可能超过重写。
- 附件同理，尤其是可下载的文档、表格和压缩包，这类文件通常没有公开备份。
动作与结果：把媒体文件按“文章标识 + 序号”重命名并单独存放。这样在新平台批量上传时，可以按文件名快速对应回正文，减少逐篇人工核对。
可以缓迁或放弃的数据
并非所有数据都值得占用迁移时间。以下内容通常可以重建，放在正文和媒体之后处理。
- 排版主题与样式配置：多数写作工具的主题无法跨平台直接复用，迁移后一般需要在新环境重新调整，抢迁的意义有限。
- 插件与扩展设置：这类配置依附于原工具的运行环境，换平台后往往不适用。
- 阅读量、点赞等统计数字：这些数据属于原平台的记录，迁移后通常无法延续，重新统计比搬运更现实。若这些数字对广告合作有证明作用，可先截图存档，但截图不等于可迁移数据。
需要说明的是，导出量突然下降或某类文件导出失败，并不能单独证明数据已经损坏。可能是导出任务排队、单次数量限制或格式兼容问题。遇到这种情况，应先分批重试并核对文件数量，再判断是否真的缺失。
迁移后的核对顺序
数据落地后，按影响面从大到小核对，比逐篇检查更有效率。
- 核对文章总数与标题列表，确认没有整篇遗漏。
- 抽查内链与图片是否可正常显示，优先检查被其他文章引用较多的旧文。
- 确认 slug 与旧地址的对应关系，为变更过的地址安排跳转。
- 最后再处理排版和样式，这一步不影响内容是否可用。
如果你使用的具体工具提供导出功能，其格式、字段和限制需要以该工具当时的实际说明为准，不同版本之间可能存在差异。把不可再生的正文与媒体先迁出，把可重建的样式与统计留在后面，是停服前更稳妥的取舍。
