扩展与调试#

扩展与调试部分是全书最后的操作层。前面章节主要解决“系统为什么这样设计、代码在哪里、运行时怎样流动”，这一部分要把这些理解重新转成工程动作：出了问题先看哪里，怀疑哪一层时该抓什么证据，要改系统时先动哪一类入口，改完以后又该怎样回归验证。

如果一部技术书只讲原理，不讲维护和排障，它离工程现场往往还差最后一公里。对 SGLang 这种多进程、多表面、多缓存层级的系统来说，这最后一公里尤其重要，因为同一个现象可能来自入口协议、调度队列、执行后半段、结构化约束或运维控制面。没有一章把这些动作明确收束，读者即使看懂前文，也未必知道该怎样真正使用这些理解。

这一部分怎样组织#

这一部分现在已经不小，但更稳的读法不是顺着二十章标题平推，而是按四类维护任务来读。

第一组：先建立证据层级#

如果你面对的是“系统出问题了，但还不知道先看哪”，先读：

这组章节解决的，是证据链怎么分层：趋势看什么，单请求看什么，时间线怎么读，不同字段为什么会互相打架。

第二组：再看在线控制面和活性问题#

如果你的问题是“系统还活着吗、能不能安全地动它、线上端点到底会改什么状态”，优先读：

这组章节的共同主题是：不是所有运维入口都处在同一风险层。只读 introspection、温和动作和强控制动作必须明确分层，否则维护章节会变成一份危险的端点清单。

第三组：把故障现象真正走到根因#

如果你已经有了初步证据，接下来该读的是：

这组章节把“工具”变成“工作流”：先判断症状类型，再决定取什么证据，再决定回哪一层代码或离线实验。

为了避免这一组仍然只像“很多排障专题”，最后建议再读 8.21 一个故障样本：从慢请求到离线复盘。这章不再新增工具，而是把本组前面分散讲过的 metrics、trace、request logger、dump 和 schedule simulator 压回同一个真实维护场景，让第 8 节第一次出现真正的“样章式闭环”。

第四组：最后再谈扩展与回归#

如果你的问题已经从“为什么坏了”转成“我要改它”，再读：

这组章节的作用，是把“理解系统”正式转成“安全地修改系统”。这也是维护层和单纯的 troubleshooting 文档最不一样的地方。

这一部分为什么必须放在最后#

把扩展与调试收在最后，不是因为它像附录，而是因为它依赖前面几乎所有章节。只有先理解请求主链路、运行时边界、调度对象、执行后半段和结构化生成约束，RequestStage、TTFT、routing_key、return_routed_experts、schedule simulator 这些工具和证据才真正有意义。

也就是说，第八部分不是“又来一组新知识”，而是把前面所有知识重新翻译成工程动作。一本成熟的系统书走到最后，应该让读者不仅知道系统怎样工作，也知道当系统不按预期工作时，自己该怎样动手。这里承担的正是这个职责。