启用多架构后Github Actions中docker/build-push-action构建缓慢咨询

开发者阿泽

2026-7-3

问题解答

一、多架构构建时间大幅增加是正常现象

启用linux/amd64和linux/arm64双架构构建后，构建时间变长完全是正常情况，核心原因有两个：

QEMU架构模拟开销：GitHub Actions默认使用x86_64架构的Runner，构建arm64镜像时需要通过QEMU模拟ARM环境执行构建指令，模拟运行的性能远不如原生架构，会额外增加大量耗时。
双架构重复构建流程：本质上要为两个架构分别完成一次完整的镜像构建，哪怕有缓存复用，也需要处理各自架构的专属层，总耗时自然比单架构翻倍（甚至更多，叠加模拟开销）。

可尝试的优化方向

若长期需要多架构构建，可配置对应架构的自托管Runner（比如ARM架构的云实例），原生构建能大幅缩短时间。
确保缓存策略生效：你已使用type=gha缓存，要保证构建过程中尽可能多的层能命中缓存，避免重复编译依赖。

二、Yarn依赖解压警告的处理

你遇到的警告是两个依赖包试图解压到同一目录，可能导致非确定性行为：

#19 7.855 warning Pattern ["string-width@^4.1.0"] is trying to unpack in the same destination "/usr/local/share/.cache/yarn/v6/npm-string-width-cjs-4.2.3-269c7117d27b05ad2e536830a8ec895ef9c6d010-integrity/node_modules/string-width-cjs" as pattern ["string-width-cjs@npm:string-width@^4.2.0"]. This could result in non-deterministic behavior, skipping.

解决思路

检查项目package.json，看是否直接声明了string-width和string-width-cjs两个依赖，若有则统一版本号，或移除其中一个（string-width-cjs是string-width的CommonJS兼容版本，通常无需同时引入）。
若依赖是间接引入的，可在package.json中添加resolutions字段强制指定统一版本：
```
"resolutions": {
  "string-width": "^4.2.0",
  "string-width-cjs": "npm:string-width@^4.2.0"
}
```
清理Docker构建过程中的Yarn缓存，确保重新安装时无残留冲突：在Dockerfile中添加RUN yarn cache clean后再执行yarn install。