论数据备份的重要性

说起博客，也将近玩了十年了，十年里从刚开始玩emlog大前端，后来发现生态没有typecho好，就慢慢转到了typecho，转到typecho不久，期间又对WordPress感兴趣，所以抛弃typecho来到WordPress的怀抱，那时候上学生活费紧缺，买的机子其实真带不动以前的WordPress不知道现在WordPress怎样呢，然后再次回到了typecho怀抱，我相信很多人都跟我一样。

于是自从博客的文章从WordPress转回typecho后，一直就有一个历史遗留问题，那就是当时用的是typecho的官方插件wordpress-to-typecho，这会导致转回来的文章使用的语法不是Markdown而是html（如下图所示），当进行文章修改的时候会有诸多不便，我不信只有我一个人有这个问题吧哈哈

还有一个问题就是typecho后台自带的备份功能，我相信当时很多小白也没少用这个来备份数据之后进行迁移或者程序升级的唯一途径，但是这个备份功能会有一个致命性问题，因为备份只会生成一个bat文件，恢复数据的时候有几率会碰上SQLSTATE[HY000]: General error:错误导致数据恢复不成功或者丢失数据，这也是我19年还是20年的时候遇到过的坑。

前几天刚好有空，刚好Cursor会员也准备过期了，就打算把这个问题一次性解决掉，于是Article Markdown Backup 插件就诞生了，启用插件后，点击控制台-文章备份与转换就能进入设置页面，很简洁，就只有四个功能

文章备份 - 备份所有文章和评论数据到JSON文件
文章恢复 - 从备份文件恢复文章和评论数据
格式转换 - 将HTML格式的文章转换为Markdown格式
文件管理 - 支持上传备份文件和选择服务器备份文件

下面是转换前和转换后的样式，插件能转换基础的markdown格式，但是如果你的主题有很多个性化的短代码，则需要自己动手修改或者在插件基础上增加更多的转换格式了：

然后就是简单的备份功能，备份功能会把你的文章数据连同评论一起导出存储为json格式保存在/usr/plugins/ArticleMarkdownBackup/backups目录，也在博主自己的网站上测试过，备份204篇文章然后全部删除然后成功恢复全部数据，在开发环境和正式部署环境都暂时没有发现丢失数据的bug（但是也建议对数据库进行及时的备份，插件只能起到临时辅助的作用，长期备份还得要备份整个数据库），如果发现bug也可以随时提出来，及时进行修复，插件是基于typecho1.3.0
进行开发，理论上支持1.2.0-1.3.0版本，更低版本的还没有测试过，个人建议可以升级到1.2.1版本。

2025/09/14更新版本

新增文章Cid管理策略（默认关闭）

• 进入后台 → 插件 → “Article Markdown Backup”插件 → 设置
• 在“策略管理”中选择“开启”，并在“CID 连贯策略”中选择一种策略
• 保存配置后生效；未开启时，不会对文章写入/发布产生影响

策略说明：

• 按最小可用位（跳过附件）
  skip：为新内容选择从1开始的最小未被有效内容或附件占用的CID；发现附件仅跳过不删除
• 按最小可用位（忽略附件，遇附件则删除）
  ignore：同上，但若最小可用位被附件占用，会删除该附件后使用该CID
• 按新增可用位（从现有最大CID开始）
  grow_skip：为新内容分配从“最大有效CID + 1”起连续递增的CID；发现附件仅跳过不删除
• 按新增可用位（忽略附件，遇附件则删除）grow_ignore：同上，但遇附件占位会删除附件后使用该CID

PS.关于全部文章Cid重新排序

评论区好友@尚寂新提及到的一起解决"文章pid和评论cid自增数连续"这个问题本地demo已经做出来了，但是在本地测试的时候出现一些问题，还在找合适的办法把历史文章和相关评论数据影响降到最小后尝试发布新版本

2025/09/15更新版本

• 新增风险策略：参考博文
• 控制台-插件-设置 开启（需要先开启策略）
• 该策略会直接修改全部文章的cid从1~N重新排列
• 该策略会删除所有附件并归还占用Cid给文章使用
• 该策略会导致重新排列前后的同一个文章链接是不一样的内容
• 该操作不可逆，建议先自行备份数据库，避免在不同环境下出现错误。
  

2025/09/22更新版本

增强了数据恢复的兼容性，新版本已优化数据导入逻辑，使其能够兼容处理备份文件中包含了非官方字段的情况，从而确保从备份数据到全新Typecho安装的平滑迁移。

插件下载：

Github官方仓库：Article Markdown Backup