incident.io 实测真实 Go 构建，决定哪些 M3 MacBook 值得买

incident.io 给每位开发者配一台 MacBook，代码库是一个近百万行的 Go 单体，本地改代码、编译、重启的循环本应控制在 30 秒内。2023 年 10 月苹果发布 M3 MacBook Pro 时，工程师们心动了，CTO Pete 立下规矩：'如果能证明值得，我们就买。' 最直接的办法是比参数、信苹果的官方跑分，或者直接给所有人买顶配。

团队把这个问题变成了一个测量问题。他们之前的热重载工具一直出问题，于是自己写了一个：给 make run 包了一层不可见的壳，每次构建结束时，就发送一个事件，记录机器平台、内存、电源、总耗时、各阶段耗时，以及触发重新构建的文件。这些事件通过 Fivetran 流入数据仓库，几周正常开发下来，收集了约 2.5 万条构建记录，而开发者完全没有改变工作流程。

分析不能简单取平均，因为 Go 的缓存导致构建差异巨大：只改注释可能一秒内完成，而改动基础包可能要重新编译大部分应用，耗时超过一分钟。他们用了一个带代码解释器的 OpenAI 助手，删掉了失败和取消的构建，只保留使用电源的构建（t 检验 p 值约 0.0014 显示电池会降频），再按缓存深度分组。他们还买了三台测试机——18GB 和 36GB 内存的 M3 Pro，以及 36GB 的 M3 Max——与现有的 M1、M2 机群比较。

数据显示，M2 相比 M1 已经是显著的提升，M3 相比 M2 只是小步改进，而 M3 Max 多出来的核心，对 Go 编译来说完全对不上它贵出的约 60% 价格。内存则揭示了一个更微妙的问题：32–36GB 的机器链接阶段几乎总能控制在 20 秒内，而 16–18GB 的机器则经常超时。于是公司给所有用 M1 的工程师升级到了 36GB 的基础款 M3 Pro，用 M2 的继续用旧机器。这篇文章在 2023 年 12 月 19 日发布，12 月 28 日登上 Hacker News，拿到了 653 分和 408 条评论。

别信纸面参数，要测真实反馈回路：把每次本地构建变成遥测数据，清理干扰项，让编译时间来决定预算

测量的是开发者真正等待的循环——真实编译、链接、重启，都是自家代码库，所以采购决策对应的是生产力，而不是营销话术。

遥测是借着换工具时悄悄加上去的，没有改变任何人的工作流，而且在决策之后数据还在持续收集。

清理了取消的构建、电池降频、Go 缓存深度等干扰因素，让小而真实的速度差异不被平均成大锅烩。

每档都买一台来测试，把价格差异变成了可验证的问题：M3 Max 贵出的 60% 没有换回任何可测的提升，而 36GB 内存解决了 18GB 机器上明显的链接缓慢。

在花钱买开发者硬件之前，先测量真实的反馈循环：收集真实的构建遥测数据，清理缓存、电源和已取消运行，让数据来选择该买的配置

订单先给了用 M1 的员工，配了 36GB 基础 M3 Pro，M2 用户则继续用原有机器。新的热重载工具还修复了旧代码重新启动的问题，为未来的硬件决策提供了可复用的基准，并绘制了 Go 依赖关系图。内存方面的发现推动了从开发者机器上移除 Docker 的计划，因为释放系统内存能加快链接。作者 Lawrence Jones 在 Hacker News 上说，整个过程花了大约 2.5 天，不到一台 MacBook 的钱，而且对招聘和品牌曝光来说物有所值。2023 年 12 月 28 日的帖子获得了 653 分和 408 条评论。