我在 v1 回顾里承诺过，v2 动手写代码之前会先有一份真正的路线图。这就是它，真正的计划，公开发出来，这样以后的我就没法假装它说的是别的东西。这篇文章只讲即将要做的事。已经上线的东西会在这个开发日志里单独成文，那本来就是这个开发日志存在的意义。
核心思路是按依赖关系排序，而不是按热情排序。我想要的几乎所有东西都挂在少数几个承重的部件上，所以这些先做，尽管它们是最没意思的那部分：
+----------------------+
| email service | the keystone
+----------+-----------+
|
+------------+----------+-----------+-------------+
v v v v
password reset contact alerts reply notifications newsletter
+---------------------+ +---------------------+
| central log service | | backups (DB+media) |
+---------------------+ +---------------------+第一波是基础设施。邮件服务排在最前面，因为我想要的四个不同功能全都要发邮件，所以邮件干脆自己成为一个小服务，带一个持久化的发件箱，其它所有东西只需要找它发东西就行。邮件真正难的部分不是 SMTP，那只是一次库调用。难的是它周围的一切：进程重启时不能丢邮件，重试和成功发送撞在一起时不能重复发送同一封邮件，还有送达率，也就是 SPF、DKIM 和 DMARC 记录这门玄学，决定了我的邮件是进收件箱还是进垃圾箱。我估计花在读 DNS 文档上的时间会比写 Go 代码还多。
备份排进第一波，因为它没有依赖，也没有借口拖延。备份难的部分不是做备份，cron 就能干这个。难的是证明它们真的能恢复。一个没测试过的备份只是一种感觉，不是真正的备份，所以计划里包括定期真的把备份恢复到一个临时数据库里，然后检查结果。还要有异地备份，因为备份放在和它要保护的东西同一块硬盘上，只能防住一种故障，而且不是那种吓人的故障。
中央日志服务是那个诚实的怪胎。一个个人博客其实不需要它，各服务自己的错误表已经够用了。我还是要做，因为它内部的模式才是重点：一个发件箱式的发送器把行批量发到一个中央汇总点，网络断了会重试，还有一个消费者要在同一批数据到达两次时依然保持正确。这些都是值得在一个爆炸半径只有我自己博客的系统上学习的模式。我把这句话写下来，是为了提醒自己别不小心把它过度打磨成企业级的样子。
第二波是所有需要邮件的东西。密码重置听起来简单，其实全是坑：重置令牌要会过期、只能用一次，而且回答不能泄露某个邮箱在这里到底有没有账户。邮箱验证顺带一起做。联系表单提醒是轻松的热身。评论回复通知需要能按每个帖子单独取消订阅，没人想因为评论过一次就永远收邮件。newsletter 是深水区：订阅者同意、永远有效的退订链接（这部分是法律要求，不是礼貌问题），还要发得足够慢，好让我这台小服务器别把自己发进黑名单。
第三波才是好玩的。一个批量照片上传器和图库，因为这个博客正慢慢变成一堆徒步照片，外加一个博客。难点在于：让几百个文件通过浏览器上传而不让一次失败毁掉整批，服务端生成缩略图，这样图库就不会把原图大小的照片一股脑塞给你的手机，还有发布前清掉 EXIF 数据，因为一张悄悄带着 GPS 坐标的照片，本质上就是披着好看夕阳外壳的隐私泄露。系列文章也放在这一波，把帖子链接成一个有顺序的合集，这更像是个建模问题，而不是编码问题。
第四波是扩大影响力。ActivityPub 是最终 boss：让帖子能联邦化，这样人们就能在 Mastodon 上关注这个博客。这意味着 actor、inbox、outbox 和 HTTP 签名，江湖传言每个服务器说的都是这份规范的一种略有不同的方言，所以大部分工作会是在调试和一堆我控制不了的服务器之间的联邦通信。Webmentions 是同一个想法更轻量的热身版。这个博客运行的三种语言的翻译助手也该放在这一波：写作时翻译一次并存下来（页面浏览绝不能触发一次 API 调用），检测原文变了的情况，好把译文标记为过时，机器产出的结果永远先落地成草稿等我编辑，绝不直接发布。还有离线阅读的 PWA，这里的经典陷阱是缓存失效，一不小心就会让读者永远看到一个过时的网站。
这些每一个都作为独立的小改动上线，而不是一个活一个月的巨型 v2 分支。哪怕只有第一波做好了，v2 也已经值了。无聊的东西先来，故意的，写在纸上。盯着我做到。