请求生命周期#

请求生命周期部分只做一件事：把“一次请求如何穿过 SGLang”先走通。它关注的是主链路上的 handoff 点，包括入口解析、协议转换、请求进入 runtime、batch 前的对象演化，以及结果怎样重新回到调用方。它故意不在这里深入 sampling、speculative decoding、KV 回收策略或 grammar backend 状态机，因为这些都属于后面的局部机制层。

这部分在全书里承担的是“先走通一条闭环”的职责。只要这条闭环稳住，读者后面再进入运行时架构、调度与内存、执行模型时，就不会把每一章都误当成新的系统，而会知道自己只是在沿同一条请求链不断下钻。

这一部分怎么组织#

这一部分现在最适合按四段来读，而不是按十个标题平推。

第一段：先走通最小主链#

先读：

这三章合起来回答的是同一个问题：请求从哪里进、由谁接住、怎样推进、怎样回包。它们提供的是最小但完整的闭环。

第二段：再看请求进入前后怎样变形#

然后读：

这组章节把请求从“外部表面上的 payload”进一步压到“系统内部真正携带的对象、元数据和附加信号”。读到这里，请求生命周期就不再只是路径图，而会开始像一套真实输入管线。

第三段：补边界条件和控制分叉#

接着读：

这组章节负责告诉你：系统并不只有一条标准生成主线。session、abort、health check、embedding、rerank 和控制请求都会改写生命周期的边界，因此必须单独看作“主链之外的正式人格”。

第四段：最后再看入口放大#

最后再读：

这样安排顺序的理由很简单：如果你还没有先把单入口主链读稳，就很容易把多 worker 模式误读成“另一个系统”；但如果主链已经稳住，这一章就会自然变成“同一条请求链被放大之后，哪些 handoff 会发生变化”。

新加的案例章放在最后，不是因为它最不重要，而是因为它承担的是收束作用：把这一部分前面分散讲过的入口、对象、batch、回包和证据字段重新压成一条完整请求样本。读完它之后，第 2 节才更像一本书里的完整 part，而不是一组互相支撑的专题章。

这一部分最值得反复抓的对象#

请求生命周期章节虽然不追求把所有机制都讲透，但它会反复回扣同一批对象，因为正是这些对象把后面的章节拴回了主线：

GenerateReqInput / EmbeddingReqInput
TokenizerManager
ReqState
Scheduler
BatchTokenIDOutput
DetokenizerManager
BatchStrOutput

这些对象在后文再次出现时，读者不应该把它们看成新名词，而应该把它们看成“请求在不同层次的不同形态”。

这一部分和前后章节怎样咬合#

这一部分前面紧接 1. 概览，因为只有先建立系统定义和读法，才知道为什么下一步必须先走请求主线。它后面接 3. 运行时架构，因为请求先走通之后，读者才更容易把 entrypoints、managers、worker 和执行壳分成正确的边界。

换句话说，这部分负责回答“请求怎样走”；下一部分负责回答“走到这些地方时，每层为什么要这样切”。两者是互补关系，不是重复关系。