runners对比：一次迁移案例复盘
runners对比最怕拿两张配置表就下结论。这次用一个可复现的 Node.js 服务迁移案例，按基线记录、双轨测试、风险核对和最终决策推进。案例不虚构节省比例，而是告诉你该采哪些数据、怎么识别缓存假快，以及何时值得从托管迁到自建。
步骤一：固定案例与测试边界
案例设定为一个使用 npm、包含单元测试并构建 Docker 镜像的 Node.js 服务。原方案采用 GitHub 托管 Linux Runner，候选方案是一台专用 Linux 自托管节点。两边使用同一提交、同一 Node.js 主版本、同一锁文件和相同工作流命令。
这一步不能省。若一边启用依赖缓存，另一边全量下载；或 Node.js 版本不同，最终数字没有比较价值。咱们只替换 runs-on 和必要的缓存路径，不顺手改测试脚本。
步骤二：先记录托管方案基线
连续运行多次，分别记录排队、代码检出、npm ci、测试、镜像构建和上传时间，同时标记缓存是否命中。别只跑一次：网络抖动、平台负载和首次下载都会让单次结果失真。
然后看失败原因与维护成本。托管节点的优势是环境干净、无需打补丁；短板可能是每次重新准备环境，以及无法直连公司内网。这里先保留原始日志，不急着判断谁赢。
步骤三：接入自托管 Runner 双轨验证
在专用虚拟机安装 Runner，使用低权限系统账户运行，只开放代码平台、镜像仓库和必要依赖源。给它设置 node-docker 标签，新建一条不执行生产部署的测试工作流，避免刚注册就接管正式发布。
运行同样次数后，重点检查两件事：热缓存是否掩盖了机器性能，以及并发任务是否争抢磁盘。再额外清空缓存跑一次冷启动，并同时触发两个任务。自建方案冷启动很慢或并发即抖动，说明之前的快只是缓存带来的表象。
步骤四：按数据决定迁移范围
这类 runners对比不该简单宣布自建或托管获胜。若主要收益来自访问内网镜像库，可以只把镜像构建与部署放到自建节点，普通测试继续托管；若队列少、任务短，自建带来的维护责任通常不值。
上线前补齐磁盘清理、离线告警、系统更新、令牌轮换和回滚方案。最终决策表至少保留五列：总耗时、排队时间、失败率、月度资源成本、人工维护时长。性能只是一票，不是唯一一票。
常见问题
Runner 性能对比至少要跑多少次？
没有适合所有项目的固定数字。实操中应覆盖冷缓存、热缓存和并发场景，并持续运行到能看出稳定区间；只比较各跑一次的数据基本没有决策价值。
为什么自托管 Runner 第一次运行很慢？
常见原因是首次拉取容器镜像、下载依赖和生成构建缓存。应把冷启动与缓存命中后的耗时分开记录，不能只展示较快的一组。
迁移到自托管后要马上停掉托管 Runner 吗？
不要。先双轨运行，确认权限、并发和清理机制稳定，再迁移特定任务。保留托管工作流也能在自建节点故障时作为回退通道。