文档、示例、测试与 benchmark 怎样支撑阅读#

这章解决什么问题#

代码导读如果只讲源码目录，仍然不够厚。因为真正高质量的技术书，不会把读者只带到实现文件前就停下，而会继续告诉读者：哪些文档是在定义公开表面，哪些示例是在暴露最小可运行路径，哪些测试是在证明维护者认为什么行为不能回归。

这一章专门补的，就是“源码之外的阅读支撑层”。没有这一层，读者当然知道 python/sglang/srt 里有哪些模块，但还不知道哪些 examples 值得先跑、哪些 docs 值得回看、哪些 tests 能帮你验证自己对系统的理解。

docs/ 不只是说明书，而是公开语义层#

官方 docs/basic_usage/、docs/advanced_features/、docs/references/ 共同承担了一件很重要的事情：它们把 runtime 和 API 的公共语义稳定下来。你可以把这些文档看成系统的“外部语义层”，它们不是实现本身，但会强烈影响你怎样理解实现。

例如 OpenAI-compatible、native API、offline engine、structured outputs、tool parser、observability 这些能力，都在 docs 中有比源码更清晰的对外描述。很多时候，先用 docs 确认“系统承诺了什么”，再回源码确认“它如何做到”，比直接读实现更稳。

examples/ 告诉你系统最小怎样用起来#

examples/runtime/README.md、examples/runtime/engine/readme.md、examples/monitoring/README.md 这类材料之所以重要，是因为它们把系统能力压成了“最小工作流”。对读者来说，这种材料的价值并不亚于源码，因为它回答了“如果我真的要跑起来，第一步应该怎样做”。

优秀技术书很少会忽视这一层。因为很多系统真正难懂的地方，不是类和函数，而是“这些东西组合起来之后，最小可运行路径是什么”。examples 恰好就是把这种组合压给读者看的地方。

test/ 和 benchmark/ 让阅读有了验证路径#

test/README.md 明确说明了 registered/、manual/、run_suite.py、suite 选择和 CI 约束，这实际上是在告诉读者：维护者如何定义“这次改动算没算破坏系统”。一旦你把测试材料纳入阅读路径，代码导读就从“知道代码在哪”升级成“知道如何证明代码还成立”。

同样，benchmark/ 也不只是辅助脚本目录。它告诉你系统怎样被衡量、哪些指标被看重、哪些工作流会被重复验证。只是它更适合放在主线之后再读，因为如果你还没理解 request lifecycle、scheduler 和 execution model，就很难真正看懂 benchmark 在测什么。

一个更完整的阅读闭环#

公开入口（README / docs）
  -> 主线源码（entrypoints / managers / executor / cache）
    -> 最小工作流（examples）
      -> 维护验证（test / benchmark）

这条闭环的价值，在于它让“阅读代码”不再是孤立行为。你不是只在看实现，而是在同时看系统怎样被介绍、怎样被运行、怎样被验证。

本章对应哪些代码路径#

这一章的主锚点包括 docs/basic_usage/、docs/advanced_features/、docs/references/、examples/runtime/README.md、examples/runtime/engine/readme.md、examples/monitoring/README.md、test/README.md 与 benchmark/ 顶层目录。

小结#

代码导读要真正有“书感”，就不能只停留在源码树。文档、示例、测试和 benchmark 共同构成了系统的外侧支撑层。把这些支撑层接回主线之后，读者拿到的就不只是实现位置，而是一整套更完整的阅读和验证路径。