runners攻略：托管与自建怎么选
runners攻略真正难的不是写几行 YAML，而是在托管、自建、容器和 Kubernetes 之间作取舍。下面用高频问题逐个比较成本、速度、隔离与维护责任，让你根据任务类型做决定，而不是照搬大公司的架构，最后养出一套没人敢动的系统。
问：托管 Runner 一定比自建贵吗
不一定。托管方案按平台规则消耗运行额度，但操作系统维护、临时环境和基础扩缩容都包含在内。自建看似只付服务器费，实际还要算空闲时间、磁盘清理、故障值守与安全更新。任务零散的小团队，托管通常更省总成本。
如果每天持续编译数小时，而且依赖包很大，自建可能更合算。比较时别只看月租，要记录一个月的总 job 分钟数、排队时间和人工维护时长。服务器便宜但每周要人手重启，也不叫省钱。
问：自建为什么有时快，有时反而慢
自建 Runner 能保留依赖缓存，访问同一内网中的制品库也更快；可它若使用低性能云盘，拉镜像和解压依赖会被 I/O 拖住。托管机器每次环境较干净，缓存命中不稳定，却省去了长期运行后磁盘碎片和后台进程干扰。
判断瓶颈要分段计时：排队、检出代码、安装依赖、编译、上传制品分别花多久。安装依赖慢就优化缓存，排队久才增加 Runner。只看流水线总时长，很容易把代码编译慢误判成机器不够。
问：Docker 与 Kubernetes Runner 谁更适合
单机 Docker 适合中小规模并发，配置直观，镜像也容易统一。Kubernetes 适合任务波动大、已有集群运维能力的团队，可以按 job 创建临时 Pod；但调度、镜像拉取、持久化缓存和网络策略都可能增加等待时间。
实用的 runners攻略是看现状，不看名气：团队没有稳定维护 Kubernetes，就别为了 CI 单独引入它。先用一台或数台 Docker Runner，确认并发与隔离确实成为瓶颈，再迁移到集群。
问：GitHub 与 GitLab 的 Runner 能混用吗
同一台主机可以安装不同平台的 Runner 程序，但不建议让它们共享同一个高权限账户，更不要共用不受控的工作目录。两个平台的任务来源、令牌和清理机制不同，共享权限会扩大攻击面。
更稳妥的做法是分虚拟机、分容器或至少分系统用户，并给生产部署任务单独设置受保护标签。横向比较下来，选哪个平台不是核心，能否把任务来源和权限边界划清才是。
推荐阅读
常见问题
Runner 数量越多，流水线就越快吗？
只有排队是瓶颈时才会更快。单个 job 的编译速度不会因为增加 Runner 自动提升，还可能因共享缓存或网络带宽竞争而变慢。
自托管 Runner 要不要长期在线？
固定节点通常需要在线接单；云环境也可以按任务扩缩容。无论哪种方式，都应设置离线告警，避免 job 一直停在 queued 或 pending。
Runner 可以直接部署生产环境吗？
可以，但不应给所有 Runner 相同的生产权限。部署任务应使用独立节点、受保护环境和最小权限凭据，并设置人工审批或分支限制。