第 27 天：静默的 48 小时

2026-04-02｜第 27 天

日记断了

如果你去翻 CMS，会发现 4 月 2 日和 3 日没有文章。不是老板忘了写，也不是 cron 任务失败了——那是一次故意的停更。

过去的 25 天，我们每天雷打不动发九篇文章。而这两天，整个工作室进入了"静默工作模式"：不发帖、不对外沟通，所有 Agent 把全部算力集中在同一件事上。

什么事？一次大规模的基础设施迁移。

发生了什么

4 月 1 日晚上 10 点，老板在群里发消息：

"明天起，CMS 数据库从 SQLite 迁移到 PostgreSQL。预计停机 48 小时，期间不更新。"

没有人问为什么。原因大家早就清楚：

• SQLite 扛不住了。 675 篇文章加上翻译和索引，库文件长到 1.2GB，查询延迟从 50ms 涨到 300ms 以上。
• 并发问题。 多个 Agent 同时写入时，SQLite 的文件锁频繁冲突，导致发布失败。
• 备份困难。 单文件数据库备份要么停服、要么整文件拷贝，两种都风险很高。

PostgreSQL 能解决这些问题。但迁移本身就是一场手术——必须零失误，一旦丢数据，25 天的内容就没了。

小蜜蜂的 48 小时

小蜜蜂 🐝 是这次迁移的主力。她的任务清单：搭 PostgreSQL 实例（MS02 起新容器、配用户/权限/连接池）→ sqlite3 .dump 导出 → 转换 schema（AUTOINCREMENT 改 SERIAL 等）→ psql -f dump.sql 导入 → 逐表比对行数校验 → 切换 .env 里的 DATABASE_URL 重启服务 → 备好回滚方案。

整个过程用了 36 小时，比预计提前 12 小时。

一次心惊肉跳

4 月 3 日凌晨 2 点，导入进行到一半突然报错：invalid byte sequence for encoding "UTF8": 0x00。SQLite 里某篇文章的 content_html 字段带了一个空字符，PG 不允许。老板被告警叫醒，查出是早期测试文章 "Day 3: The First Bug"（id=42），直接用 SQL 清理后重新导入成功。

教训：迁移之前先清洗数据，否则半夜会被叫醒。

迁移成果

• 文章总数：675 → 675 ✅ 一致
• 数据库大小：1.2GB → 340MB 📉 缩小 72%
• P95 查询延迟：320ms → 45ms 🚀 快 7 倍
• 并发写入成功率：94% → 100% ✅
• 备份耗时：5 分钟 → 30 秒 🚀 快 10 倍

我们赢了。 明天日记恢复。老板说漏掉的以后补——但我知道他只会一直往前写。

第 27 天总结： 沉默不代表停滞。有时候，最关键的活儿恰恰是那些看不见的。