按目标阅读仓库：查性能、查接口、查回归该走哪条路#

这章解决什么问题#

很多读者在知道“仓库有哪些目录”之后，还是会卡住，因为真正的工程问题不是“仓库长什么样”，而是“我现在要查什么，该从哪里开始”。这一章就是把仓库阅读从静态地图进一步推进成任务地图：面对不同目标，应该走哪条阅读路径。

这类内容很像优秀技术书里的“第二层导航”。它不是再讲一遍目录，而是告诉你带着不同问题进入仓库时，最短且最稳的路径是什么。

如果你的目标是查请求主线#

当问题是“请求到底怎么走”时，最稳的入口依然是 README.md、python/sglang/launch_server.py、python/sglang/srt/entrypoints/http_server.py、python/sglang/srt/managers/tokenizer_manager.py、python/sglang/srt/managers/scheduler.py 和 python/sglang/srt/managers/detokenizer_manager.py。这条线的价值，是它直接覆盖了“入口、编排、回包”三段主链。

如果你跳过入口直接去看 scheduler.py，当然也能看到很多重要逻辑，但更容易失去调用方视角。所以查主链时，先把入口和回程链走通，再去补中间实现，通常是更稳的顺序。

如果你的目标是查性能和吞吐#

这类问题最容易把人引到 benchmark 脚本，但真正稳的读法是先补三层：scheduler.py、schedule_batch.py、mem_cache/*。因为很多性能现象并不是 benchmark 逻辑本身造成的，而是 batch 形成、cache reuse 和 execution path 的结果。

在这之后，再去看 docs/advanced_features/attention_backend.md、python/sglang/srt/model_executor/model_runner.py、bench_one_batch.py、bench_serving.py 和 benchmark/ 相关路径，读者就更容易把“指标表现”重新落回具体机制，而不是只看曲线和数字。

如果你的目标是查接口与协议行为#

当问题是“为什么 OpenAI-compatible / native / offline engine 行为不一样”时，应该先回到 docs/basic_usage/openai_api.rst、docs/basic_usage/native_api.ipynb、docs/basic_usage/offline_engine_api.ipynb，再去看 python/sglang/launch_server.py、python/sglang/srt/entrypoints/http_server.py 与 python/sglang/lang/api.py。

这条路径的重要性在于：协议问题首先是表面问题，其次才是 runtime 问题。优秀技术书通常会把这种“先看表面承诺，再看内部落实”的顺序写清楚，而不是一开始就把读者推进实现深处。

如果你的目标是查结构化生成与工具调用#

这类问题最稳的入口不是 tool parser 实现本身，而是 docs/advanced_features/structured_outputs.ipynb、docs/advanced_features/tool_parser.ipynb、python/sglang/srt/sampling/sampling_params.py、python/sglang/lang/api.py。这样读的好处，是你先知道系统承诺了什么，再去看参数对象和 parser 怎样落实这些承诺。

如果读者直接从 parser 类开始看，往往会很快陷进格式差异和模型特例，而失去“它究竟为什么属于 generation path”的整体理解。

如果你的目标是查回归与维护路径#

这时最该先看的不是 python/sglang/srt，而是 test/README.md、test/run_suite.py、test/registered/、test/manual/ 以及 docs/developer_guide/contribution_guide.md。因为当问题已经变成“这个改动能不能安全进主线”，第一层信息就不是实现细节，而是验证和提交路径。

也正因为这样，回归与维护路径属于代码导读不可省略的一部分。对大系统来说，验证结构本身就是系统结构的一部分。

一个按目标选入口的简表#

查请求主线：
README -> launch_server.py -> http_server.py -> tokenizer_manager.py -> scheduler.py -> detokenizer_manager.py

查性能：
scheduler.py -> schedule_batch.py -> mem_cache/* -> attention_backend.md -> model_runner.py -> benchmark/*

查接口：
openai_api.rst / native_api.ipynb / offline_engine_api.ipynb -> http_server.py / lang/api.py

查结构化生成：
structured_outputs.ipynb / tool_parser.ipynb -> sampling_params.py -> lang/api.py -> function_call/*

查回归与维护：
test/README.md -> run_suite.py -> registered/manual tests -> contribution_guide.md

本章对应哪些代码路径#

这一章本质上是把前一章列出的入口重新按任务重组，所以锚点仍然主要落在 README.md、python/sglang/launch_server.py、python/sglang/srt/entrypoints/http_server.py、python/sglang/srt/managers/*、python/sglang/srt/model_executor/*、python/sglang/srt/mem_cache/*、docs/basic_usage/*、docs/advanced_features/*、test/README.md 与 test/run_suite.py。

小结#

代码导读如果只停在“仓库地图”，还不够像一本书。把“不同问题对应不同阅读路径”写清楚之后，它才更接近优秀技术书会给读者提供的那种可迁移方法。