测试、CI 与回归路径#

这章解决什么问题#

如果一章技术书只讲系统如何工作，却不讲“怎么证明它还工作”，那它对维护者来说仍然是不完整的。SGLang 的测试和 CI 体系之所以值得单独成章，就是因为它直接定义了哪些行为被认为是必须长期成立的。

这一章解决的问题，不是“怎样写一条测试命令”，而是“为什么测试和 CI 应该被看作系统语义的一部分”。这对 runtime 项目尤其重要，因为很多错误不是接口错误，而是性能、状态、并发或边界条件的回归。

`test/README.md` 为什么比很多人想象得更重要#

test/README.md 不只是开发说明，它在实际上定义了测试区域、suite、CI runner、failfast 策略以及注册方式。换句话说，它告诉你维护者如何把系统行为切成一组可以长期执行的验证路径。

从技术书角度看，这类文档的价值在于：它把“哪些行为是系统承诺的一部分”显式写了出来。只要你知道测试怎么组织，很多代码路径的优先级就会重新排序，因为你能看出哪些部分被反复保护、哪些部分仍然更像实验区域。

`registered / manual / unit` 的差别不是目录细节#

registered/、manual/、unit/ 这些目录名看上去像测试工程细节，但其实它们提供了理解系统的另一条横切线。

unit 更像“组件级语义是否成立”
registered 更像“CI 认为必须长期回归的行为”
manual 更像“对环境敏感、适合本地或专项排查的路径”

只要把这种差别看清楚，读者就不再把测试当成“代码完成后的补充材料”，而会把它看成“系统边界在维护层的投影”。

`run_suite.py` 和 suite 组织方式提供了什么线索#

test/run_suite.py 和 test/README.md 一起给出的，并不只是命令行参数，而是一套 suite 划分逻辑：哪些测试需要 CPU、哪些需要 GPU、哪些进入 nightly、哪些应该保持轻量。对理解系统而言，这很有价值，因为它告诉你：维护者认为系统最敏感的部分在哪里，哪些测试成本高，哪些路径会因为环境差异被特殊看待。

从阅读角度说，这也提供了另一种“系统地图”：不是按模块分层，而是按验证成本和验证粒度分层。优秀技术书经常会补这种第二张地图，因为它能帮助读者把“理解系统”变成“理解系统如何被守住”。

一个维护者视角的最小检查框架#

改动前：
1. 这次变更影响的是哪个抽象层？
2. 对应有没有 unit / registered / manual 路径？

改动后：
1. 先跑最小 unit / local test
2. 再跑对应 suite 或 registered 路径
3. 必要时补 benchmark / accuracy / nightly 验证

这张清单的价值不在于它足够完整，而在于它能把“我改了代码”立刻转成“我应该怎么证明这次改动没有伤到主线”。这正是 maintainer 视角和普通读者视角的分水岭。

本章对应哪些代码路径#

这一章最重要的锚点包括 test/README.md、test/run_suite.py、test/registered/、test/manual/、docs/developer_guide/contribution_guide.md 以及一批 unit / function_call / observability / mem_cache 测试目录。

小结#

测试和 CI 不是实现完成后的尾声，而是系统语义在维护层的延续。把这一章补进来之后，整本书就不再只回答“它怎么工作”，还开始回答“它怎么被持续证明仍然工作”。这正是一本更成熟技术书应该具备的厚度。