看起来你当前构建的最大瓶颈完全在JavaScript混淆步骤——从日志看这一步就花了近5分钟，直接吃掉了总构建时间的70%以上。加上Docker缓存策略没真正复用混淆后的文件，才导致总时间卡在19-20分钟。下面是针对你的场景定制的优化方案，咱们一步步来把时间压到5-6分钟以内：

一、先解决核心痛点：修复混淆缓存，让它真正跨构建复用 #

你当前的.obf-cache是在Docker镜像内部创建的，每次COPY . .之后的层都是新的，缓存文件根本带不到下一次构建。必须把混淆缓存移到GitHub Actions的宿主缓存（而不是Docker内部），这样跨构建才能复用。

具体操作： #

1. 把混淆步骤从Dockerfile里移到GitHub Actions宿主环境执行（更高效，还能并行处理文件），同时给混淆缓存加独立的GitHub Actions缓存：

# 在GitHub Actions workflow中添加以下步骤，代替Dockerfile里的混淆逻辑
- name: Install JavaScript Obfuscator
  run: npm install -g javascript-obfuscator

- name: Cache obfuscated JS files
  uses: actions/cache@v4
  with:
    path: .obf-cache
    key: obf-cache-${{ hashFiles('dist/**/*.js') }}
    restore-keys: |
      obf-cache-

- name: 并行混淆JS文件（核心提速点）
  run: |
    mkdir -p .obf-cache
    # 用GNU Parallel并行处理所有JS文件，默认runner是2核，换成8核runner会更快
    find ./dist -type f -name "*.js" ! -path "*/spec/*" ! -path "*/dto/*" | parallel -j $(nproc) '
      jsfile={}
      hash=$(sha256sum "$jsfile" | cut -d" " -f1)
      cached=".obf-cache/$hash.js"
      if [ -f "$cached" ]; then
        cp "$cached" "$jsfile"
        echo "[cache-hit] $jsfile"
      else
        javascript-obfuscator "$jsfile" --output "$jsfile" --compact true --self-defending true
        cp "$jsfile" "$cached"
        echo "[obfuscated] $jsfile"
      fi
    '

这样调整后，单线程5分钟的混淆任务，用2核runner能压到1.5分钟左右，换成8核large runner的话，40秒就能搞定。

二、优化Docker构建层缓存，减少无效重建 #

你当前的Dockerfile层顺序可以调整，让更稳定的层放在前面，避免每次源码变化都重建所有层：

优化后的多阶段Dockerfile #

# 基础依赖层：几乎不会变，缓存后永远复用
FROM node:22-alpine AS base
RUN apk add --no-cache \
  build-base \
  cairo-dev \
  pango-dev \
  jpeg-dev \
  giflib-dev \
  librsvg-dev \
  python3 \
  make \
  g++
RUN npm install -g npm@latest
WORKDIR /app

# 依赖安装层：只有package*.json变化时才重建
FROM base AS deps
COPY package*.json ./
# 用npm ci代替npm install，CI环境下更快更稳定
RUN npm ci

# 构建层：只在源码变化时重建
FROM deps AS build
COPY . .
COPY .env.production .env
ENV TEST_LICENSE=production
ENV NODE_OPTIONS=--max-old-space-size=4096
RUN npm run build

# 最终镜像：只复制需要的文件，大幅减小镜像体积
FROM base AS final
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/.env .env
CMD ["node", "--max-old-space-size=4096", "/app/dist/main.js"]

调整后，base和deps层几乎不会重建，只有源码变化时才会跑build层，能节省至少2-3分钟的无效等待时间。

三、调整混淆参数，进一步压缩耗时 #

如果你的业务对代码混淆的级别要求不是最高，可以调整参数减少计算量：

• 把--self-defending true改成false，能减少30%-50%的混淆时间
• 增加--split-strings false（如果不需要字符串拆分混淆），再提速10%-20%
• 只混淆核心业务JS文件，跳过第三方依赖或DTO、Spec等非核心文件（你已经做了部分，可再细化）

调整后的混淆命令示例：

javascript-obfuscator "$jsfile" \
  --output "$jsfile" \
  --compact true \
  --self-defending false \
  --split-strings false

四、升级GitHub Actions Runner #

默认的GitHub Actions runner是2核的，换成8核的Large Runner（runs-on: ubuntu-latest-8-cores），并行处理混淆文件时速度会提升3-4倍。

注意：Large Runner需要在GitHub仓库设置中启用，虽然有少量费用，但对于19分钟的构建，节省的时间成本远超过费用。

预期效果 #

按照上述方案优化后：

1. 首次构建：总时间能压到5-6分钟以内（混淆1.5分钟+构建3分钟+其他步骤1分钟）
2. 后续构建：如果源码没有变化，混淆步骤几乎秒级完成（缓存全命中），总时间能到3分钟以内
3. 镜像体积也会大幅减小，因为最终镜像只复制了必要的文件

内容来源于stack exchange