CodSpeed 基准护栏

基准回归为什么总在上线后才被发现

性能问题往往在代码合并很久之后才浮出水面。一次看似无害的重构——换掉排序算法、调整查询缓存策略、给序列化结果加个字段——可能让关键路径的耗时悄悄上升几毫秒。在高 QPS 服务里，这几毫秒会被放大成明显的延迟毛刺，但审查者盯着 PR diff 看半天，也看不出哪里会变慢。

更棘手的是，退化通常不是「某次提交突然变慢」，而是几十个 PR 累积出的缓慢爬升。等监控报警时，已很难定位是哪个变更引入的。

这个技能如何工作

该技能把 CodSpeed 的基准测试能力接入 PR 工作流：在 CI 中运行基准测试，与基线比较，在合并前把退化暴露在 PR 上。

核心能力与关键步骤：

• 前置条件：仓库中已有可执行的基准测试或基准测试命令；有 CI 系统（如 GitHub Actions）；有 CodSpeed 账户或认证流程用于存储和比较结果。
• 运行基准测试：通过 codspeed run 执行，例如 codspeed run cargo（Rust）或 codspeed run pnpm vitest bench（Node.js）。
• 多语言覆盖：支持 Python、Rust、Node.js、Go、C/C++ 等。
• 灵活执行模式：codspeed exec -- python my_script.py 直接跑脚本；codspeed exec --mode walltime -- node app.js 用 walltime 模式测真实耗时。
• 本地或 CI 均可：先在本地验证，再接入 GitHub Actions、GitLab CI 等流水线。

适用边界与注意点

• 本技能只负责执行基准测试并上报结果，不会自动生成基准代码——仓库里必须先有可运行的基准测试或明确的命令入口。
• 结果比较依赖 CodSpeed 平台，需要配置账户与认证；完全离线的环境无法保存历史基线。
• 基准测试本身的稳定性会影响结论：冷启动和机器负载波动都可能制造假阳性，建议在固定、隔离的 CI runner 上运行，并结合多次采样降低噪声。
• 它适合可量化的性能场景（吞吐、延迟、内存）；对基准测试难以覆盖的架构级问题（如并发模型设计），它帮不上忙。