black-jupyter 是 CI lint 任务的主要成本，占用约 218 秒（总任务约 6 分钟），且每次 CI 运行都会重新格式化所有文件，导致缓存无法生效。ruff format 在完整代码库上只需约 2 秒，且与 pre-commit 配置中锁定的 ruff 版本一致，可显著提升 CI 效率。
值得精读，因为它是基础设施的重大改进，可显著提升 CI 速度。但主要变更都是机械性的格式化，审查重点应放在配置变更和验证方法上。
无讨论。PR 作者在 body 中已详细说明了变更动机、方案和验证方法，并提供了清晰的审查指引。
.pre-commit-config.yaml 中将 black-jupyter hook 替换为 ruff-format，保持相同的位置（在 ruff lint hook 之后）和排除列表。ruff-format 的默认配置与 black 的默认配置一致，无需额外配置。pre-commit run ruff-format --all-files，对整个代码库应用 ruff 格式化。变更仅涉及代码风格（如隐式字符串连接、空行、换行等），不改变任何语义。.git-blame-ignore-revs 文件（由后续 PR #37695 完成）以忽略大规模格式化提交对 git blame 的影响。开发者编辑器中配置的 black 格式化工具可能需要调整为 ruff，但 pre-commit 会自动修正。| 文件 | 模块 | 状态 | 重要度 |
|---|---|---|---|
.pre-commit-config.yaml |
CI 配置 | modified | 7.44 |
python/sglang/srt/mem_cache/mamba_radix_cache.py |
内存缓存 | modified | 6.47 |
分析完成后，这里会展示 LLM 生成的相对完整源码片段和详细注释。
当前评论区没有形成足够清晰的争议点或结论，后续有更多讨论时会体现在这里。
主要风险是与其他进行中的 PR 产生冲突，因为重新格式化影响了几乎所有 Python 文件（约 1400 个）。此外，开发者本地工作流可能需要适应新工具，但 ruff 与 black 格式兼容，差异很小。无运行时风险。
对用户无直接影响（仅代码格式变更）。对系统 CI 效率提升显著，lint 任务时间可减半。对团队开发者需要轻微适应，但工具链兼容性好，且后续 PR 已处理 git blame 影响。
当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。
参与讨论