第一版范围与阅读地图#

这一章真正解决什么#

这章不是礼貌性的开场白，而是替整本书划边界。面对 SGLang 这样的系统，读者最容易犯的错误有两个：一个是把它当成 API 手册读，另一个是把它当成一棵巨大的源码树直接往下钻。前者会失去实现与权衡，后者会失去整体边界。第一版范围与阅读地图的任务，就是先把这两种偏法都挡住。

因此，这一章要先回答的不是“这本书多厚”，而是“这本书准备沿着哪条主线往里讲，哪些问题会先讲，哪些问题会延后，哪些问题则刻意不作为首版目标”。只要这条边界足够清楚，后文再厚也不容易散。

第一版明确讲什么#

第一版优先覆盖八条主脊梁：

SGLang 的外部形态和系统定位
一次请求怎样进入、编排、执行并回包
Serving surface、SRT、manager、worker 和执行壳的边界
waiting queue、batch 成形、KV cache 与请求对象的关系
token generation、sampling 和输出后半段语义
结构化生成、tool workflow 与接口表面
从概念回到仓库源码时，最稳定的阅读路径
维护、排障、扩展和回归验证的工作流

这种范围不是“先讲常识，后讲难点”，而是先把全书真正共享的主线立起来。后面很多章节会反复回扣同一批对象，例如 Req、ScheduleBatch、ForwardBatch、SamplingParams 和 ReqTimeStats，也是因为这些对象正好贯穿了上述八条主脊梁。

第一版刻意不讲什么#

第一版不追求三类内容。

第一，不把整套上游仓库写成逐文件百科。
第二，不把所有实验特性、所有后端分支、所有模型适配细节都平均展开。
第三，不把未经源码或文档核实的性能结论、复杂度判断和架构意图写成事实。

这不是保守，而是一本系统书的基本取舍。对仍在快速演进的项目来说，首版最重要的不是把所有枝叶都挂上去，而是先让主干足够稳，读者离开书页之后知道下一步该去哪里追。

这一版的推荐阅读顺序#

如果你准备顺着整本书往下读，最稳的顺序通常是：

这个顺序的重点，不是按“浅到深”排，而是按“先定边界，再走主链，再解释内部，再回到源码和维护”排。只要顺序不乱，后面章节即使很厚，读者也不至于不知道自己当前站在哪一层。

如果你不是线性阅读#

很多工程师不会从第一页一直读到最后，而是带着问题进来。这时更有效的不是记住目录，而是按问题找入口：

我想先搞清系统到底是什么：
概览 -> 为什么是 SGLang -> 核心不变量与阅读检查点

我想先搞清请求怎样流动：
请求生命周期 -> 运行时架构

我想先搞清性能与资源管理：
调度与内存 -> 执行模型

我想先搞清 output schema、tool workflow 和接口表面：
结构化生成与 API

我想回源码、排障或改系统：
代码导读 -> 扩展与调试

这张阅读地图真正想做的，是把“不同问题该进哪条路”显式说出来，而不是默认读者会自己在一百多章之间找到节奏。

为什么范围说明本身也是技术内容#

很多计算机书会把范围说明藏进前言，写成几段礼貌性的免责声明。但对系统书来说，范围说明本身就是第一层设计判断。因为一本书怎样切问题，往往和系统本身怎样切边界是相通的。

SGLang 特别需要这种写法。它同时有 frontend language、runtime surface、OpenAI-compatible 接口、native API、offline engine、structured output、observability、模型扩展与测试路径。只要书稿一开始不先说清“为什么沿这条路读”，读者很快就会看到很多局部机制，却看不到它们为什么会在同一套系统里共存。

读完这一章之后应当带走什么#

如果这一章起作用了，读者离开这里时应该已经明确三件事：

这本书优先解决的是主线和边界，而不是 API 穷举。
后文的顺序是有理由的，不能随意把调度、执行或代码导读前置成独立文章。
当阅读过程中开始迷路时，应该回到“我现在在问哪一类问题”这个层面，而不是盲目在章节之间跳转。

优秀技术书不会只给目录，它还会给读法。这一章承担的正是这个职责。