一本书是怎么被写出来的 书架

导读

lab 写书服务端调度代码手册

先别急着打开那 1770 行的 server.ts。先看一个数字:从你在 App 里点下「写书」,到一本书出现在书架上,中间要经过 八步、三条引擎腿、两次落盘登记、一次扣费和至多一次退款——而负责调度这一切的代码,主体都集中在 server.ts 的写书段落和 book-legs.ts、inflight.ts 两个小模块里。

这本书就是这些代码(连同它的测试和发版脚本)的手册。读者设定只有一种:要维护这套系统的工程师——包括三个月后已经忘了为什么这样写的作者自己。

这套系统解决什么问题

「写一本书」对 lab 来说是一个坏脾气的任务:跑几十分钟到几小时、烧的是别人家的订阅配额、中途可能被发版重启杀死、而用户付的是真金白银的算力。普通的「起个后台任务跑完回调」在这里处处踩坑:

怎么读

顺序读:第一章给全景,之后每章拆一段,事故簿(第十章)收尾。每章固定四段——这段代码在哪、它做什么、为什么这样写、怎么排查——急用的时候可以直接翻每章最后一节,照命令表查。

所有代码引用都逐字对照过源码;所有函数名、常量名、日志前缀都可以在仓库里 grep 到。书里讲的每个机制背后都有一次真的事故,日期和书名都在源码注释里写着——如果哪天你改动了某段代码,记得回头看看它挡过的那次事故。

大白话:这不是一本「架构设计书」,是一本「出事了翻哪页」的手册。系统设计里没有多少深思熟虑,大多是事故驱动的补丁——但每个补丁都钉了测试、留了注释、写清了为什么。维护它的正确姿势是尊重这些补丁的来历。

一本书是怎么被写出来的 · 王建硕
费曼式写法 · 由多个 AI 代理撰写与互相审校