（整理、非新实测。以下失败记录均为 2026-10-01 以后 Lite 仓 test-install 的真实 run 结论，时间与结论以 GitHub Actions 页面为准；价格与链接见文末。）
先说结论
同样一个红叉，至少分三种死法，修法完全不同：
- 断言失败：脚本或安装步骤真的跑挂了，改代码才有用。
- runner 未获得：job 排队 15 分钟后被判定失败，根本没执行，改脚本没用。
- cancelled：job 被取消，也没有失败步骤日志，同样不是脚本的错。
分不清这三种，就会像无头苍蝇一样改一通本来没问题的脚本。
真实记录：三次 README-only 提交的红叉
Lite 仓的 test-install 有 4 个 job：install.ps1（windows-latest）、install.sh（ubuntu-latest）、install.sh（windows-latest）、install.sh（macos-latest）。
- 第 27 篇导链提交 e923585：前 3 个 job 通过（11 秒、6 秒、12 秒），macos-latest 耗时 15 分 2 秒，结论是“The job was not acquired by Runner of type hosted even after multiple attempts”，并附 macOS arm64 runner 容量约束提示。
- 第 28 篇导链提交 1fdfedc：同样前 3 个 job 通过，macos-latest 耗时 30 分 36 秒，结论是 cancelled，无失败步骤日志。
- 第 30 篇导链提交 7412f80：同样前 3 个 job 通过（9 秒、5 秒、13 秒），macos-latest 耗时 15 分 3 秒，结论与第 27 篇相同，也是未获得 runner。
三次改动都只是 README 里加一行 dev.to 文章导链，没有碰安装脚本。中间第 29 篇导链提交 50dcc86 的同名 run 是全绿的（10 分 14 秒），说明 macOS job 时好时坏，不是改动本身的问题。
怎么分流：只看三处
- 先看 4 个 job 各自的结论，不要只看总 run 的红叉。前 3 个通过、只有 macOS 一个 job 出问题时，优先怀疑 runner 侧，而不是安装脚本。
- 再看失败 job 有没有失败步骤日志。未获得 runner 和 cancelled 都没有可执行的失败日志——没有日志，就没有可改的断言。
- 最后看耗时。断言失败通常几秒到几十秒就挂；15 分钟、30 分钟这种量级，更像是排队或取消，不是脚本跑挂。
顺带排除的噪音
这几次 run 里还有两条既有通用标注：Node.js 20 弃用提示（actions/checkout@v4 被强制跑在 Node.js 24 上）、ubuntu-latest 迁移提示。它们在成功和失败的 run 里都出现，不是本次失败的原因，不用为此改 workflow。
和前面几篇的区别
- 花括号规则篇讲的是脚本本身的 bug：bash 变量后紧跟中文时边界解析出错，CI 断言失败是真的。
- token scope 篇讲的是文件根本没进仓：gh token 缺 workflow 权限，workflow 文件推不上去。
- 本篇讲的是第三种情况：文件进了仓、脚本也没错，CI 还是红了——因为 runner 没拿到。三种红法，三种修法，不要混成一种。
不用场景
- 如果失败 job 有明确的断言日志，本篇不适用，先修日志指出的那一步。
- 如果 4 个 job 全挂，本篇的分流也不适用，先看共性原因。
价格与链接
Lite 版免费版已含 /test、/review、/commit 3 条命令与安装脚本，完整版为 10 条全量。完整版早鸟 ¥9.90 限前 100 份，正式 ¥19.90。
