发布流水线卡顿的排查顺序流水线停在 Pending、构建阶段变慢或部署等待超时原因不一定是 Runner 资源不足。排查时先把一次运行拆成排队、拉取源码、恢复缓存、安装依赖、测试、构建镜像、推送制品和部署验证等阶段。每个阶段记录开始结束时间、执行节点、缓存命中与失败原因才能判断等待发生在哪里。不要先提高并发或给所有 Job 加 CPU。更多并发可能加剧共享磁盘、网络和镜像仓库的争用更大的 Runner 也无法修复缓存键频繁失效、依赖安装重复执行或测试串行等待。先看同一提交在不同 Runner 上的阶段分布再用一次受控改动验证假设。从排队和缓存开始Pending 通常与可用 Runner、标签匹配、并发上限、受保护分支规则或配额有关。构建实际开始后检查克隆深度、依赖缓存、Docker layer 缓存和制品下载是否命中。缓存的键要同时考虑锁文件、架构和工具版本只按分支名缓存可能带来过期依赖所有 Job 共用一个宽泛键也会造成污染。Dockerfile 的层次会影响缓存复用先复制依赖声明并安装再复制频繁变动的源码通常比每次先COPY . .更容易命中缓存。远程缓存能帮助不同 Runner 复用层但要验证仓库权限、缓存推送失败的降级行为和敏感文件是否误入层中。build_image: stage: build script: - docker buildx build \ --cache-from typeregistry,ref$CI_REGISTRY_IMAGE:cache \ --cache-to typeregistry,ref$CI_REGISTRY_IMAGE:cache,modemax \ --tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA \ --push .示例需要配合项目的构建器驱动、仓库权限和镜像保留策略测试它不能保证每次都命中缓存。缓存拉取或推送失败应在日志中明显标出避免把“构建变慢”误解为编译器回归。区分测试并行与资源争用测试可以按模块或分片并行但要保证每个分片独立不共享会互相覆盖的数据库、端口或临时目录。对需要外部服务的集成测试设置固定的超时、清理与重试边界无限重试只会把下游故障伪装成流水线卡顿。构建、测试和部署 Job 使用不同 Runner 标签时也要监测队列长度避免某一种任务长期饿死。磁盘 I/O、镜像仓库限流和网络带宽常常比 CPU 更早成为瓶颈。检查 Runner 的磁盘空间、inode、缓存大小和网络错误率再决定是否清理过期缓存或扩充容量。清理命令应限定目标与保留窗口不能在共享 Runner 上无差别删除仍被其他 Job 使用的资源。最后为每次优化保留基线选取相同的提交、依赖状态和 Runner 类型比较各阶段耗时与失败率而不是只比较一条流水线的总时长。这样能知道改动究竟缩短了排队、依赖安装还是镜像构建也能在回归时迅速定位。