从 README 到 benchmark：一条更完整的仓库主线#

这章解决什么问题#

前面几章已经把“按目标读仓库”“通过 tests 读系统行为”“遇到 bug 从哪里下手”这些角度分别讲开了，但对一本更厚的技术书来说，还需要再把这些角度重新串起来：如果一个读者准备从零进入这个仓库，一路走到 benchmark 与 profiling，他的最佳路径到底是什么？

这一章要解决的，就是“如何把分散的阅读策略重新压成一条更长、更稳的仓库主线”。

为什么从 README 开始仍然是对的#

很多进阶读者会天然觉得 README 太浅，不值得花太多时间。但对一个复杂系统来说，README 的价值从来不是“够不够深”，而是“能不能帮你在最早阶段避免误判系统形状”。SGLang 尤其如此，因为它同时有 frontend language、server runtime、native API、offline engine、structured output 和 observability 这些外部表面。

因此，把 README 放在阅读链最前面，并不是迁就新手，而是把系统形状先讲正。只要形状一开始没看偏，后面进入 srt、tests 和 benchmark 才不至于越读越散。

为什么阅读路径应该最终落到 benchmark#

很多代码导读会在“知道源码在哪”之后结束，但大系统真正的终点往往不是源码，而是“怎样证明你的理解和修改在运行上站得住”。这也是为什么这章要把 benchmark 和 profiling 拉进来。

对 SGLang 这种 inference runtime 而言，benchmark 不是额外附录，而是“理解是否最终落地”的一层证据。你理解了请求主线、scheduler、cache、execution model 之后，最终总要回到 benchmark / profiling 问：这些理解怎样影响真实运行结果。

一条更完整的阅读路径#

README
  -> __init__.py / lang/api.py / launch_server.py
    -> entrypoints / managers / model_executor / mem_cache / observability
      -> docs/basic_usage / advanced_features
        -> examples/runtime / examples/monitoring
          -> test/README.md / run_suite.py / registered tests
            -> benchmark_and_profiling / bench_one_batch / bench_serving / benchmark/*

这条路径的意义，不是让读者机械照抄，而是说明：一个系统性的技术读法，最终应该从“项目怎样介绍自己”走到“项目怎样证明自己”。这正是技术书比普通源码介绍更有价值的地方。

本章对应哪些代码路径#

这一章的锚点横跨 README.md、python/sglang/__init__.py、python/sglang/lang/api.py、python/sglang/launch_server.py、python/sglang/srt/*、docs/basic_usage/*、docs/advanced_features/*、examples/runtime/*、test/README.md、test/run_suite.py、python/sglang/bench_one_batch.py、python/sglang/bench_serving.py 与 docs/developer_guide/benchmark_and_profiling.md。

小结#

一章真正成熟的代码导读，不应该只把读者送到源码门口，而应该把他一路带到 benchmark 与 profiling 证据层。到这一步，代码导读才真正从导航工具长成了一章书。