微信后台的“素材管理”页面，我盯着那个不断旋转的加载图标已经超过十秒了。这他妈就是我的数字资产？几百篇长文，几十万字的思考，就卡在这个破服务器响应上。2018年了，公众号的流量分发越来越像抖音，算法推荐权重高得吓人，我这种靠深度内容起家的，哪天被彻底沉底了都不知道。不行，必须撤。
我受够了这种把命脉交给别人服务器的心情。这感觉就像住在别人房子里，房东随时可能涨租或者把你扫地出门。我得把我的东西，一字不差，连同数据痕迹，全部搬回我自己的硬盘。这不是备份，这是数字资产的战略转移。
开干。思路很清晰，但每一步都是坑。首先，不能直接用爬虫去抓公众号前台页面，那太慢，而且容易被封。我的入口是微信公众平台后台的“素材管理”接口。用 Chrome 开发者工具抓包，找到那个返回 JSON 数据的请求。关键参数是 `offset` 和 `count`，一次最多拉 20 条。写个 Python 脚本，用 `requests` 库模拟登录后的 Cookie 和 Token，开始循环遍历。这里第一个坑就来了：微信后台对高频请求极其敏感，连续发请求大概率会触发风控，弹验证码或者直接踢下线。我不得不给每个请求之间加上随机延时，`time.sleep(random.uniform(2, 5))`，模拟真人操作。看着进度条慢吞吞地走，心里焦躁得像火烧。
数据拉下来了，是 JSON 格式，里面包含了每篇文章的标题、封面图 URL、原文链接、摘要，还有最重要的——`content` 字段，那是完整的 HTML 源码。但这只是第一步。HTML 源码里混杂了微信的各种样式标签、`data-src` 懒加载、还有那些烦人的代码块高亮样式。我需要把它清洗成干净的 Markdown，并且最好能还原排版。我用上了 `html2text` 库，但默认配置效果很垃圾，微信的代码块会被转得一塌糊涂。我不得不自己写正则表达式，去匹配 `` 和 `
` 标签，把它们转换成带语言标识的 Markdown 代码块格式。图片更麻烦，`data-src` 需要替换成 `src`，然后还要把图片一张张下载到本地，并修改 Markdown 里的图片链接为相对路径。这里用上了多线程下载，不然几百篇文章的配图能下到明天。光有文字和图片还不够。我要的是“资产”的完整快照。所以阅读量、点赞数、精选留言，一个都不能少。阅读量数据在另一个接口，需要每篇文章的 `msgid` 去单独请求。留言又是另一个接口，而且分页逻辑还不一样。脚本越写越长，异常处理越来越多。`try...except` 块里全是各种网络超时、JSON 解析错误、偶尔返回空数据的处理逻辑。整个脚本运行起来，就像在走钢丝，你不知道哪一步会触发微信后台的警报。
最耗时的环节是生成 PDF。我要的可不仅仅是打印网页。我用 `weasyprint` 引擎，把清洗后的 HTML 加上我自定义的 CSS 样式（仿公众号排版，但去掉了所有广告和无关元素），一篇文章一篇文章地渲染成 PDF。这个过程极度消耗内存和 CPU，我不得不把任务队列化，控制并发数量，不然电脑直接卡死。看着命令行窗口里刷过的日志：“正在处理第 45 篇：《2017年SEO算法变动全解析》… 下载图片 3/5… 渲染PDF… 完成。” 一种奇特的满足感混杂着焦虑涌上来。我在抢救一些正在缓慢沉没的东西。
整整跑了八个小时。脚本终于停在了 “All done.” 的提示符。我打开输出文件夹，里面整整齐齐：一个 `articles.md` 的索引文件，按时间排序；一个 `markdown` 文件夹，里面是每篇的纯净 Markdown；一个 `pdf` 文件夹，是排版精美的离线版本；一个 `images` 文件夹，存放着所有配图；甚至还有一个 `data.json`，包含了所有元数据（发布时间、阅读、点赞、留言）。我用 `tar` 命令把它们打成一个压缩包，看着那个几十兆的文件，名字是 `wechat_archive_20180920.tar.gz`。
把它拖到我的 NAS 和一块加密的移动硬盘里。心里那块石头才算落地。什么信息流，什么算法推荐，什么平台规则突变。去他妈的。我的文字，我的思考，我的数据，从此有了一个不会消失的坐标。这次“大撤退”让我彻底明白了一件事：Flovico 的终极堡垒，永远是我自己能完全控制的独立服务器。平台只是渠道，资产必须私有。这不是偏执，这是互联网手艺人，在算法时代最后的，也是必须的抗脆弱性防御。
