# GitHub Actions 内建包管理为何被吐槽为「最差」 > 拆解 GitHub Actions 在依赖引用、缓存策略与安全模型上的设计缺陷，给出可落地的自救清单。 ## 元数据 - 路径: /posts/2025/12/08/github-actions-package-manager-worst/ - 发布时间: 2025-12-08T21:47:39+08:00 - 分类: [systems-engineering](/categories/systems-engineering/) - 站点: https://blog.hotdry.top ## 正文 在 CI/CD 的竞技场里，GitHub Actions 凭借「零门槛」与 Marketplace 生态迅速占领 repo。然而当开发者把 YAML 从 30 行写到 800 行后，几乎都会发出同一声吐槽：这大概是体验最差的「包管理器」。没有 lock 文件、没有依赖树、没有语义化版本，却要让全球 560 万工作流每天跑着不可复现的第三方脚本。本文把「最差」拆成三条硬伤疤：设计缺陷、性能黑洞、安全雷区，并给出仍在泥潭中的工程自救方案。 ## 设计缺陷：语法、语义、复现性三重缺失 Actions 的依赖声明只有一行 `uses: owner/repo@ref`，看似简洁，实则把包管理最基础的三件事全推给用户： 1. 无变量插值：`uses` 字段禁止 `${{ }}`，导致无法动态切换源，企业内网隔离只能靠「搜-替-改」三连。 2. 无语义版本：`@v1` 只是 git 标签的「字符串等于」匹配，不存在 `^1.2.3` 的区间语义；一旦上游强制推送，本地 CI 立刻漂移。 3. 无 lock 机制：既没有 `package-lock.json`，也没有 `go.sum`，回滚只能指望人工记 commit hash。GreptimeDB 团队在重构 Release 流水线时吐槽：「YAML 弱 DSL 让 183 行膨胀成 800 行，本质就是把依赖树写死在注释里」。 结果是「可复制构建」成为幻觉：同一套 workflow，在不同时间点跑，拉到的 action 可能已是完全不同的代码。 ## 性能黑洞：缓存失效与重复下载 GitHub 提供的 `actions/cache` 只解决「文件级」缓存，对 action 本身却毫无记忆： - 跨 job 不共享：matrix 策略下，每个 slice 都要重新 clone 同一 action，几十秒到数分钟不等。 - 跨分支不共享：PR 触发的新 ref 被视为全新命名空间，旧缓存直接失效。 - 缓存键简陋：默认只哈希 yarn.lock 这类文件，若 action 内部升级了子依赖，缓存不会失效，导致「命中却错误」。 实测一个 20 个 job 的工作流，仅下载 actions 就耗时 6 分 32 秒，占整次 CI 43% 时间。开发者只能把「自建 runner + 本地镜像」当标配，却失去了云原生弹性扩缩的意义。 ## 安全雷区：供应链攻击与权限扩散 Google Project Zero 早在 2020 年就指出，Actions 的工作流命令注入让「打印一条日志就能写环境变量」。更严重的是依赖面： - 无完整性校验：uses 字段无法附带 SHA256，只能相信 git tag；一旦上游 repo 被劫持，恶意代码立刻获得 GITHUB_TOKEN 写权限。 - 权限过度：默认 `permissions: write-all`，而第三方 action 仅需一行 `echo "::set-env"` 即可把机密带到外部服务器。 - 不可审计：没有依赖树，也就无法生成 SBOM；企业合规团队面对几百个 `@main` 只能人工翻 commit。 2025 年供应链报告显示，16 万个公共工作流直接 `git clone` 主分支，相当于把生产密钥挂在别人阳台上晾晒。 ## 工程自救：版本锁定、本地缓存、最小权限 在 GitHub 官方给出真正的 lock 文件之前，只能「靠自己」： 1. 版本锁定：所有 `uses` 强制写死 commit SHA，例如 `actions/checkout@b4ffde65f`，并在 CODEOWNERS 里要求双审才能升级；配合 renovate-bot 自动提 PR，但合并仍需人工二次确认。 2. 私有镜像：把高频 action 同步到企业内网仓库，用 `ghcr.io/org/actions/xxx` 替代官方源；同时在内网 runner 上预 clone，实现「一次下载，全厂共享」。 3. 缓存策略：在 job 级别把 `/opt/actions-cache` 打 tar 上传到 S3，用「repo+commit」做 key，让矩阵 job 先尝试拉取缓存，再回退到官方源；实测可把 6 分钟缩短到 45 秒。 4. 最小权限：在 workflow 顶部显式声明 `permissions: contents:read`，按需单独打开 `id-token`、`pull-requests`；对第三方 action 一律用 `permissions: {}` 先锁死，再白名单放行。 5. 准入评审：内部维护「允许列表」仓库，任何新增 action 需提交 PR，通过 Trivy + Scorecard 扫描后方可合并；runner 端用 Open Policy Agent 实时校验，拒绝不在列表内的镜像。 ## 结语：把「最差」变成「待改进」 GitHub Actions 的「包管理」仍停留在 2014 年的 git clone 时代：没有版本解析、没有依赖树、没有完整性校验。它把「灵活性」最大化，却把「可维护性」「可复现性」「安全性」全部推给下游。社区已经用脚投票——Zig、Dillo 等项目纷纷迁出，GreptimeDB 则花 3 个月把 800 行 YAML 拆成可审计的 Makefile + Dockerfile。 要终结「最差」标签，GitHub 至少需要： - 引入类似 `actions.lock.yml` 的语义锁文件； - 允许在 uses 字段声明 hash，并提供原生签名验证； - 把 action 缓存提升到「包」级别，支持跨 job、跨 repo 共享； - 在 Marketplace 侧显示安全评分与 SBOM 下载。 在那一天到来前，开发者只能把上面五招自救清单贴在 PR 模板里，然后继续对每一行 `@main` 保持警惕——毕竟，CI 流水线一旦「随机失败」，最先被怀疑的永远是那行没有锁版本的第三方 action。 --- 参考资料 [1] GreptimeDB 团队：《GitHub Actions?! 想说爱你不容易》，InfoQ，2023. [2] Felix Wilhelm, Google Project Zero：《Workflow commands injection in GitHub Actions》, 2020. ## 同分类近期文章 ### [Apache Arrow 10 周年：剖析 mmap 与 SIMD 融合的向量化 I/O 工程流水线](/posts/2026/02/13/apache-arrow-mmap-simd-vectorized-io-pipeline/) - 日期: 2026-02-13T15:01:04+08:00 - 分类: [systems-engineering](/categories/systems-engineering/) - 摘要: 深入分析 Apache Arrow 列式格式如何与操作系统内存映射及 SIMD 指令集协同，构建零拷贝、硬件加速的高性能数据流水线，并给出关键工程参数与监控要点。 ### [Stripe维护系统工程：自动化流程、零停机部署与健康监控体系](/posts/2026/01/21/stripe-maintenance-systems-engineering-automation-zero-downtime/) - 日期: 2026-01-21T08:46:58+08:00 - 分类: [systems-engineering](/categories/systems-engineering/) - 摘要: 深入分析Stripe维护系统工程实践，聚焦自动化维护流程、零停机部署策略与ML驱动的系统健康度监控体系的设计与实现。 ### [基于参数化设计和拓扑优化的3D打印人体工程学工作站定制](/posts/2026/01/20/parametric-ergonomic-3d-printing-design-workflow/) - 日期: 2026-01-20T23:46:42+08:00 - 分类: [systems-engineering](/categories/systems-engineering/) - 摘要: 通过OpenSCAD参数化设计、BOSL2库燕尾榫连接和拓扑优化，实现个性化人体工程学3D打印工作站的轻量化与结构强度平衡。 ### [TSMC产能分配算法解析：构建半导体制造资源调度模型与优先级队列实现](/posts/2026/01/15/tsmc-capacity-allocation-algorithm-resource-scheduling-model-priority-queue-implementation/) - 日期: 2026-01-15T23:16:27+08:00 - 分类: [systems-engineering](/categories/systems-engineering/) - 摘要: 深入分析TSMC产能分配策略，构建基于强化学习的半导体制造资源调度模型，实现多目标优化的优先级队列算法，提供可落地的工程参数与监控要点。 ### [SparkFun供应链重构：BOM自动化与供应商评估框架](/posts/2026/01/15/sparkfun-supply-chain-reconstruction-bom-automation-framework/) - 日期: 2026-01-15T08:17:16+08:00 - 分类: [systems-engineering](/categories/systems-engineering/) - 摘要: 分析SparkFun终止与Adafruit合作后的硬件供应链重构工程挑战，包括BOM自动化管理、替代供应商评估框架、元器件兼容性验证流水线设计