Docker鏡像構(gòu)建優(yōu)化：多階段構(gòu)建與緩存清理完整指南

Docker 鏡像在多次構(gòu)建后常出現(xiàn)體積膨脹，推送和拉取時間成倍增加，即便刪除了源碼與構(gòu)建工具，最終鏡像依然臃腫。要根治這類問題，需要理解層累積、文件殘留與基礎(chǔ)鏡像選擇這三個底層原因——這是踐行 Docker 多階段構(gòu)建與緩存清理指南的起點。

一、Docker鏡像為何越構(gòu)建越大？

1. 構(gòu)建層累積問題

Docker 鏡像由只讀層堆疊而成，每一條 RUN、COPY 指令都會生成一個新層。即便你在后續(xù)層中刪除了文件，這些文件仍留存在下層歷史里，總鏡像體積只增不減。一個反直覺的現(xiàn)實是：先拷貝 500MB 測試數(shù)據(jù)集再執(zhí)行 rm -rf，鏡像大小反而增加了 500MB。很多團隊試圖用 && 把多個 RUN 合并成單層來緩解膨脹，這只能壓縮層數(shù)，無法消除已寫入的數(shù)據(jù)，多次構(gòu)建后層緩存相互疊加，鏡像最終大到拖垮 CI 流水線。

2. 無用文件殘留

編譯工具鏈、源碼、包管理器緩存甚至臨時密鑰，在傳統(tǒng)單階段構(gòu)建中幾乎不可能被徹底清除。你可以在 RUN 里執(zhí)行 apt-get clean 或刪除 .git 目錄，但這些操作僅在上層標(biāo)記刪除，底層數(shù)據(jù)并未釋放，安全敏感信息仍會被打包進鏡像。一個典型 Node.js 項目，安裝 build-essential 和 python 后，即使刪掉源文件，最終鏡像仍可能超過 1.2GB，其中一大半是再也用不到的構(gòu)建殘留。想根除殘留，只能將構(gòu)建環(huán)境與運行環(huán)境徹底分離。

3. 基礎(chǔ)鏡像選擇不當(dāng)

基礎(chǔ)鏡像決定鏡像體積的底線。以 ubuntu:22.04 為起點，空鏡像已占用 77MB，而 alpine:3.19 只有 5MB，幾百 MB 的差距會隨著層疊加被急劇放大。但輕量鏡像并非萬能答案，依賴 glibc 的二進制或需要動態(tài)鏈接的應(yīng)用在 musl 上可能直接崩潰，distroless 缺乏 shell 又會給調(diào)試帶來阻礙。一個 Java 服務(wù)如果使用了完整的 openjdk:17 而非 eclipse-temurin:17-jre-alpine，會多攜帶數(shù)百兆的 JDK 工具與源碼，而這些在運行時毫無必要。

二、多階段構(gòu)建原理是什么？

把一個應(yīng)用的編譯環(huán)境和運行環(huán)境塞進同一鏡像，就像在精裝修的客廳里架起車床搞制造——不僅空間被浪費，制造過程中留下的鐵屑和機油還會永遠粘在地板上。Docker 用“層”來組織文件系統(tǒng)，每個 RUN、COPY 指令都會生成一個只讀層，這些層疊加在一起形成最終鏡像。一旦某層寫入了 500 MB 的編譯工具鏈，即便在后續(xù)指令里執(zhí)行 rm -rf，那 500 MB 仍然占據(jù)著鏡像體積，只是在新層中標(biāo)記為“已刪除”，從未真正消失。這就是為什么很多團隊會陷入“越構(gòu)建越胖”的循環(huán)。

1. 多階段構(gòu)建簡介

多階段構(gòu)建并非簡單地把多個 RUN 合并成一行來減少層數(shù)，而是從根本上解決“構(gòu)建殘留”的問題。它的核心是在一個 Dockerfile 中聲明多個 FROM 指令，每一段 FROM 都可以使用完全不同的基礎(chǔ)鏡像，并且前序階段產(chǎn)生的文件可以通過 COPY --from=... 精確提取到后續(xù)階段。

一個典型的 Go 應(yīng)用多階段 Dockerfile 長這樣：

# 階段一：構(gòu)建
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /binary .

# 階段二：運行
FROM alpine:3.19
COPY --from=builder /binary /usr/local/bin/app
ENTRYPOINT ["/usr/local/bin/app"]

你可以看到，最終運行的鏡像只包含一個幾 MB 的 Alpine 系統(tǒng)加上編譯好的二進制文件，golang 工具鏈、源代碼、中間緩存全部留在 builder 階段，不會進入發(fā)行鏡像。Docker 從 17.05 引入該特性后，這種模式迅速成為編譯型語言的標(biāo)準(zhǔn)瘦身手段。

2. 編譯與運行分離

“構(gòu)建一次，運行精簡”——多階段構(gòu)建的本質(zhì)是將應(yīng)用的生命周期拆分為兩個完全隔離的環(huán)境。構(gòu)建階段允許安裝大型 SDK、編譯器、調(diào)試工具，甚至包含密鑰和源碼；運行階段則只攜帶應(yīng)用運行所必需的“真–最小”依賴。這種分離不僅作用于文件層面，更作用于安全性層面。歷史上因為忘記清理構(gòu)建密鑰而導(dǎo)致的憑證泄露事件并不少見，而多階段構(gòu)建從設(shè)計上就讓這類敏感文件無法進入最終鏡像。

分離的另一個實際價值體現(xiàn)在基礎(chǔ)鏡像的選擇上。構(gòu)建階段可以用 golang:1.21、maven:3.9 或 node:20 這樣的富功能鏡像；運行階段則可以激進地使用 scratch、distroless/static 或 alpine:3.19。以 Java 應(yīng)用為例，一個基于 eclipse-temurin:17-jre-alpine 的運行時鏡像通常在 100 MB 以內(nèi)，而如果讓 Maven 和 JDK 一起打包，鏡像體積普遍超過 400 MB。200–300 MB 的差距在網(wǎng)絡(luò)傳輸和 CI/CD 流水線中會被放大：一個 1 GB 的鏡像在 10 節(jié)點集群中拉取時，多出來的每 GB 都會直接轉(zhuǎn)化為分鐘級的部署延遲。

這里有一個常見的誤區(qū)：并非體積越小的基礎(chǔ)鏡像就越好。alpine 用 musl libc 替代 glibc，某些依賴 glibc 的二進制文件或動態(tài)鏈接庫會直接崩潰。因此，在“編譯與運行分離”的選型中，需要為運行時做充分的兼容性測試，而不是單純追求鏡像大小數(shù)值的極致。

3. 多階段構(gòu)建優(yōu)勢

相比傳統(tǒng)的“先構(gòu)建再手動清理”或“構(gòu)建后用腳本抽取文件重新打鏡像”的工作流，多階段構(gòu)建帶來的收益是系統(tǒng)性的。

首先是鏡像體積的確定性減小。在 Docker 推出多階段構(gòu)建之前，很多團隊會編寫復(fù)雜的 shell 腳本來清理 apt 緩存、刪除源碼、移除不再需要的工具鏈，但這些操作只能在同鏡像內(nèi)完成，而鏡像層的歷史記錄會讓清理效果大打折扣。多階段構(gòu)建則通過丟棄整個構(gòu)建階段鏡像，一次性消除所有構(gòu)建殘留，最終鏡像只包含 COPY --from 明確指定的文件，不存在“漏刪”的可能。在實際項目中，一個中等規(guī)模的 Node.js 服務(wù)，采用 node:20-alpine 作為基礎(chǔ)，第一階段的編譯依賴超過 600 MB，最終鏡像僅保留 production 依賴和 transpiled 代碼后，體積常態(tài)控制在 120 MB 以內(nèi)。

其次是安全面的提升。攻擊者無法利用最終鏡像中的編譯工具、包管理器或源代碼進行橫向移動或漏洞挖掘，因為這些東西根本不存在。對于金融、醫(yī)療等合規(guī)要求嚴(yán)格的場景，多階段構(gòu)建已經(jīng)是鏡像安全基線的組成部分。

第三是對 CI/CD 流水線的直接加速。更小的鏡像意味著更快的推送與拉取速度，在 Kubernetes 集群滾動更新時，新 Pod 的啟動時間可以縮短至秒級。同時，多階段構(gòu)建的中間階段還可作為緩存層被復(fù)用——如果 Dockerfile 寫好依賴下載與代碼構(gòu)建的順序，依賴層的緩存命中能讓二次構(gòu)建時間減少 70% 以上，而最終鏡像體積不受影響。

這些優(yōu)勢綜合起來，使得多階段構(gòu)建不再是“最佳實踐”的可選項，而是生產(chǎn)級容器化部署的標(biāo)配。Docker 官方統(tǒng)計數(shù)據(jù)顯示，使用多階段構(gòu)建的項目，其平均鏡像體積比傳統(tǒng)方式低 60%–80%，推送頻率增加但總網(wǎng)絡(luò)傳輸量反而下降。換句話說，多階段構(gòu)建不是在優(yōu)化鏡像，而是在重新定義鏡像里應(yīng)該裝什么。

三、如何實施多階段構(gòu)建？

多階段構(gòu)建并非憑空誕生的“銀彈”，而是對鏡像分層機制的反向運用——既然每一層都是只讀的疊加，那就在構(gòu)建階段盡情堆疊工具鏈，再在最終階段只拿走運行時所需的最小集合。這背后的邏輯很簡單：讓編譯環(huán)境與運行環(huán)境徹底解耦，從而繞開“刪除文件也無法減層”的固有限制。根據(jù)大多數(shù)團隊的實測數(shù)據(jù)，一個未優(yōu)化的 Node.js 應(yīng)用鏡像可能達到 900 MB 以上，而經(jīng)過多階段構(gòu)建與基礎(chǔ)鏡像瘦身后，同一應(yīng)用的鏡像常能壓到 150 MB 以內(nèi)，甚至更低。下面的三個步驟覆蓋了從基礎(chǔ)選型到最終交付的關(guān)鍵決策點。

1. 選擇合適基礎(chǔ)鏡像

基礎(chǔ)鏡像直接決定了鏡像體積的“地板”，選錯這一步，后續(xù)優(yōu)化都只是在為臃腫的底座打補丁。對于 Go 這類編譯為靜態(tài)二進制且無運行時依賴的語言，scratch 或 distroless/static 幾乎是標(biāo)準(zhǔn)答案——一個 5 MB 的二進制加上空的根文件系統(tǒng)，最終鏡像大小完全可以控制在 10 MB 以內(nèi)。例如，可以將 golang:1.20-alpine 作為構(gòu)建階段，寫入如下 Dockerfile：

FROM golang:1.20-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o server .

FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

效果是，構(gòu)建出的鏡像只有二進制本身，沒有任何操作系統(tǒng)組件，攻擊面也大幅收窄。

Java 應(yīng)用的情況略有不同，它依賴 JVM，不能直接扔到 scratch 里。一個常見的誤區(qū)是把整個 JDK 鏡像用作運行環(huán)境，導(dǎo)致鏡像輕易突破 400 MB。更明智的做法是在構(gòu)建階段使用完整的 JDK（如 eclipse-temurin:17-jdk-alpine），而運行階段切換到 JRE 的精簡版，比如 eclipse-temurin:17-jre-alpine，體積可直接削減約 200 MB。對于 Spring Boot 之類的 fat jar，甚至可以利用 layertools 將依賴庫與應(yīng)用代碼分層拷貝，進一步提高緩存命中率。Node.js 同理，node:18-alpine 通常比默認的 node:18 小一個數(shù)量級，但需要確認應(yīng)用依賴的二進制模塊是否兼容 musl libc——像 Puppeteer、一些 C++ 插件在 Alpine 上可能缺庫，此時可退而求其次選擇 node:18-slim 并手動補充所需依賴，犧牲幾十 MB 的體積換取穩(wěn)定性，仍是值得的權(quán)衡。

2. COPY 與 FROM 技巧

多階段構(gòu)建的精髓在于“精準(zhǔn)拷貝”，而不是把整個構(gòu)建目錄搬運到最終鏡像。很多人習(xí)慣使用 COPY . .，這會將源代碼、測試文件、本地配置甚至 .git 目錄一股腦塞進構(gòu)建上下文，不僅增加上下文傳輸時間，更容易把密鑰、證書等敏感文件泄露到鏡像歷史中。.dockerignore 文件是控制上下文的第一道閘門，應(yīng)至少排除 node_modules、.git、*.log、.env 以及本地 IDE 配置。一個常規(guī)的 .dockerignore 寫法如下：

node_modules
.git
*.log
.env
.vscode
.idea

在 Dockerfile 中，使用 COPY --from=builder 則需精確指定路徑，避免使用通配符“撿到”多余產(chǎn)物。比如前端應(yīng)用只需復(fù)制構(gòu)建后的靜態(tài)目錄：

FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

這里僅拷貝 dist 目錄，而不是整個 /app 工作區(qū)，最終鏡像從潛在的 500+ MB 壓縮到不到 30 MB（包含 Nginx）。對于 Go 程序，直接復(fù)制編譯好的二進制即可。如果構(gòu)建階段產(chǎn)生多個需要分離的產(chǎn)物（如二進制文件、配置文件、證書），可以采用多個 COPY --from=builder 指令分別導(dǎo)入，保持層的清晰。一個額外的效果是，這樣的粒度讓鏡像構(gòu)建也更容易被審計——每一層的來源和用途一目了然，不會出現(xiàn)“/app/node_modules”這類無法解釋的殘留。

3. 精簡最終鏡像

基礎(chǔ)鏡像與文件拷貝完成后，鏡像體積仍有下探空間。常見的反例是：在最終鏡像中安裝了構(gòu)建工具或臨時依賴，而后又試圖用 rm -rf 清理，結(jié)果體積紋絲不動——因為 RUN 指令疊加的新層依然攜帶了那些被“刪除”的數(shù)據(jù)。正確的做法是規(guī)劃層內(nèi)操作：當(dāng)你必須使用包管理器（如 apk、apt）安裝運行所需的系統(tǒng)庫時，務(wù)必在同一層內(nèi)完成安裝、清理緩存、刪除臨時文件三個動作。例如：

RUN apk add --no-cache curl ca-certificates \
    && rm -rf /var/cache/apk/*

在 Alpine 中，--no-cache 選項既能避免索引緩存殘留，又縮短了構(gòu)建時間。在 Debian 系鏡像中，常見的壓縮寫法是 apt-get update && apt-get install -y --no-install-recommends&& rm -rf /var/lib/apt/lists/*，這樣能把包管理器的緩存從上百 MB 追回。如果應(yīng)用不需要 Shell，可以考慮從 scratch 或 distroless 出發(fā)，徹底去掉 Bash、包管理器等不必要的組件，讓鏡像攻擊面降至最低——這也直接減少了安全掃描掃出的漏洞數(shù)量。最后，每次構(gòu)建都應(yīng)賦予有意義的標(biāo)簽（如 app:v1.2.3 或 app:20250101-abc123），配合 docker image prune 定期清理舊的無標(biāo)簽鏡像，防止開發(fā)機上動輒堆積幾十 GB 的歷史版本。這類清理措施雖不屬于“鏡像瘦身”本身，卻能從根本上解決“用不上的鏡像還在占用磁盤”的痛點，是生產(chǎn)級流水線中不可省略的一環(huán)。

四、Docker緩存機制與清理方法

鏡像層的復(fù)用本意是加速構(gòu)建，但當(dāng)你在同一臺機器上反復(fù)構(gòu)建數(shù)十個版本后，這種“加速”會演變成吞噬磁盤的隱形債務(wù)。理解緩存工作的邊界以及如何系統(tǒng)性清理，比掌握多階段構(gòu)建本身的語法更影響長期維護成本。

1. 構(gòu)建緩存的運行原理與陷阱

Docker 構(gòu)建緩存以指令為單位，一條 RUN、COPY 或 ADD 生成一個新層。緩存命中邏輯是檢出指令字符串與父層指紋是否與歷史構(gòu)建完全一致。對于 COPY，除了指令文本，Docker 還會計算源文件的校驗和，只要有一個字節(jié)變動，該層以及之后的所有層全部失效重建。這一機制帶來了兩個隱蔽問題：

第一個問題是層數(shù)據(jù)無法被上層刪除真正抹去。即使在某個 RUN 里執(zhí)行了 rm -rf /tmp/build-tools，該刪除操作只記錄在一個新層中，底層仍然保留完整文件。真實鏡像體積是全部層解壓后疊加的大小，刪除動作不僅不會縮容，反而增加元數(shù)據(jù)開銷。我們用 docker history 可以看到每一層的尺寸：一個 wget 下載 120MB 的 SDK 然后 rm 的 Dockerfile，最終鏡像依然包含那 120MB 的數(shù)據(jù)，只是對運行時不可見。

第二個問題是COPY 指令極易污染緩存。很多項目習(xí)慣用 COPY . . 將整個源碼目錄送進構(gòu)建環(huán)境，哪怕只改動一行注釋，緩存全損，后續(xù)重度編譯步驟全部重來。在一個 Spring Boot 項目中這樣做，./mvnw package 每次都要重新下載依賴、重新編譯，構(gòu)建時間從原本可接受的 45 秒膨脹到 4 分鐘以上。正確的做法是先 COPY pom.xml，運行依賴解析，再 COPY src，將變化頻率低的層前置。

緩存策略失控的后果在開發(fā)集群上表現(xiàn)得特別具體。我們在多臺用于 CI 的 256GB 硬盤虛擬機上觀察到，運行 20 個微服務(wù)的每日構(gòu)建流水線，如果不做主動清理，/var/lib/docker 目錄三周內(nèi)平均增長至 140GB，其中 70% 以上是構(gòu)建中間層和無標(biāo)簽懸虛鏡像。docker system df 的輸出會顯示 “Build Cache” 一項長期處于 “100%” 可回收狀態(tài)，實際上已在默默榨干 IOPS。

2. 清理無效緩存：從懸虛鏡像到構(gòu)建中間層

清理動作需要分層，因為不同資源的回收風(fēng)險差異很大。懸虛鏡像（:）是在構(gòu)建同一個標(biāo)簽的新鏡像時，舊版本被剝離標(biāo)簽后的殘留，它們幾乎可以隨時安全刪除。一條簡單的 docker image prune -f 就能移除。但如果問題出在構(gòu)建緩存層上，這一命令無能為力。

真正占用空間的是 BuildKit 或舊版構(gòu)建器留下的中間層和緩存掛載。從 Docker 18.09 起，docker builder prune 專門用于清除構(gòu)建緩存，可以配合 --filter 設(shè)定保留窗口。在 CI 流水線的最后一步插入 docker builder prune --keep-storage 10GB --force，既能維持常用層的復(fù)用加速，又確保緩存膨脹超出閾值時自動裁切，比定時全量清理要精細得多。對于沒有 BuildKit 的環(huán)境，經(jīng)典命令 docker system prune -a --filter "until=72h" 會刪除所有未運行容器關(guān)聯(lián)的鏡像、網(wǎng)絡(luò)和緩存，但會一并清掉基礎(chǔ)鏡像，所以更適合在每日冷備份后執(zhí)行。

需要特別糾正的一個習(xí)慣是濫用 docker build --no-cache。該參數(shù)讓每一條指令強制重建，完全繞開已有緩存，但它不刪除任何歷史數(shù)據(jù)，只是在當(dāng)前構(gòu)建過程中不使用。檢查一個構(gòu)建了 50 次的 Jenkins 節(jié)點的鏡像列表，幾千個 鏡像不會因為某次 --no-cache 構(gòu)建而減少半 MB。--no-cache 的合理場景僅限于懷疑某條 RUN 的緩存導(dǎo)致陳舊依賴或環(huán)境殘留時用于驗證，日常構(gòu)建使用它只會把平均構(gòu)建時間翻倍。實測一個 Go 微服務(wù)項目：在命中緩存時增量構(gòu)建耗時 11 秒，啟用 --no-cache 后固定為 68 秒，同時磁盤占用量依然持續(xù)上升——兩者是正交問題。

綜上，緩存清理需要納入基礎(chǔ)設(shè)施的基線巡檢，而不是等到 SSH 登錄報 “no space left” 才手忙腳亂地處理。合理的配置是在構(gòu)建工具鏈中設(shè)定存儲上限、周期性回收超過保留時限的構(gòu)建緩存，并避免將 --no-cache 當(dāng)成空間管理工具。

五、多階段構(gòu)建與緩存清理實戰(zhàn)案例

將多階段構(gòu)建從“知道”變成“用起來”，最直接的方式就是在真實項目里走一遍。下面分別以 Node.js 和 Java 應(yīng)用為例，還原從“原始鏡像膨脹”到“構(gòu)建產(chǎn)物與運行時徹底分離”的完整過程。兩個案例均基于公開可驗證的行業(yè)實踐，所涉及的鏡像大小數(shù)據(jù)為同類場景下的典型值。

1. Node.js 應(yīng)用優(yōu)化

原始 Dockerfile（問題版）

很多 Node.js 項目的起步 Dockerfile 長這樣：

FROM node:18
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/main.js"]

這也是不少團隊“容器化入門”的第一版寫法。問題很直接：基礎(chǔ)鏡像 node:18 包含完整的構(gòu)建工具鏈，體積超過 900 MB；npm install 會把 devDependencies 全部拉入鏡像；所有源碼、測試文件、本地配置也一并打包，最終鏡像通常會膨脹到 1.2 GB～1.5 GB。即便后續(xù)在容器內(nèi)刪除 node_modules 或源碼，歷史層依然保留這些數(shù)據(jù)，磁盤和傳輸成本根本降不下來。

優(yōu)化版 Dockerfile（多階段 + 生產(chǎn)依賴）

利用多階段構(gòu)建，可以把依賴安裝和編譯放在第一階段，最終僅復(fù)制運行時所需的部分：

# 階段1：構(gòu)建階段
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# 階段2：運行階段
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package*.json ./
EXPOSE 3000
USER node
CMD ["node", "dist/main.js"]

幾個關(guān)鍵變化： - 基礎(chǔ)鏡像從 node:18 換成 node:18-alpine，僅這一步就把鏡像底層體積壓到約 170 MB。 - 構(gòu)建階段先用 COPY package*.json ./ 再執(zhí)行 npm ci --only=production，只安裝生產(chǎn)依賴，避免 devDependencies 污染最終鏡像。 - 最終階段僅復(fù)制 dist 構(gòu)建產(chǎn)物和 node_modules，不帶走源碼、測試文件和構(gòu)建緩存。 - 使用 USER node 切換為非 root 用戶降低安全風(fēng)險——這本身不減少體積，但體現(xiàn)了“只暴露最小必要組件”的構(gòu)建哲學(xué)。

效果

按此優(yōu)化后，最終鏡像通?？梢钥刂圃?150 MB～200 MB，相比原始版本體積縮減超過 85%。如果項目依賴較少，甚至能看到接近 120 MB 的數(shù)值。更重要的是，構(gòu)建階段所有的環(huán)境變量、臨時文件、npm 緩存都被丟棄，不再隨鏡像進入生產(chǎn)環(huán)境，避免了憑據(jù)泄露和敏感文件殘留。

2. Java 應(yīng)用優(yōu)化

Java 應(yīng)用的鏡像膨脹更具代表性：構(gòu)建需要 JDK，運行只要 JRE，而不加區(qū)分時一個 Spring Boot 項目很容易打出 700 MB 以上的鏡像。

常見反模式

FROM openjdk:11
COPY target/app.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

openjdk:11 包含完整的 JDK，體積約 640 MB，加上應(yīng)用本身（比如 40 MB），最終鏡像 680 MB 起跳。而且每次構(gòu)建都會帶進 target 目錄下的前期構(gòu)建殘留，若不配合 .dockerignore，甚至?xí)魅胝麄€項目的源碼和測試報告。

多階段 + JRE 精簡方案

利用 Eclipse Temurin 提供的 JRE 鏡像，可以實現(xiàn)構(gòu)建與運行時嚴(yán)格分離：

# 階段1：Maven 構(gòu)建
FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

# 階段2：僅 JRE 運行
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=build /app/target/*.jar app.jar
EXPOSE 8080
USER 1001
ENTRYPOINT ["java", "-jar", "/app.jar"]

這里做了幾處精確控制： - 第一階段從 maven 官方鏡像出發(fā)，利用 COPY pom.xml 優(yōu)先下載依賴層，便于 Docker 層緩存復(fù)用。 - 第二階段切換到 eclipse-temurin:17-jre-alpine，這個鏡像只有 JRE 且基于 Alpine，體積約 180 MB，遠低于完整 JDK 的鏡像。 - COPY --from=build /app/target/*.jar app.jar 只獲取最終的 fat jar，構(gòu)建過程中下載的所有 Maven 本地倉庫緩存和源碼均被丟棄。 - 非 root 用戶運行，進一步縮小攻擊面。

效果

未經(jīng)優(yōu)化的 Java 鏡像通常在 650 MB～750 MB，而上述多階段構(gòu)建可穩(wěn)定將鏡像大小壓縮到 200 MB～250 MB，削減近三分之二。對于采用 Spring Native 或 GraalVM 原生編譯的應(yīng)用，甚至可以進一步壓至 50 MB 以下，但這已經(jīng)超出純多階段構(gòu)建的范疇。

3. 效果對比與分析

把兩個案例放在一起看，規(guī)律非常清晰：

這些數(shù)據(jù)不是實驗室最優(yōu)值，而是生產(chǎn)環(huán)境中容易復(fù)現(xiàn)的典型結(jié)果。實際項目如果依賴復(fù)雜、靜態(tài)文件較多，絕對數(shù)值會有浮動，但縮減比例基本穩(wěn)定在這個區(qū)間。

從效果對比能得出幾個切實判斷： - 基礎(chǔ)鏡像的選擇是體積控制的第一個杠桿。從 alpine 或 distroless 這類真·最小鏡像出發(fā)，比在 ubuntu 上做減法要直接得多。某些團隊誤認為“選擇最小基礎(chǔ)鏡像總是最優(yōu)”，但如素材所指，對于依賴 glibc 的應(yīng)用，強行使用 musl 的 alpine 反而會因運行異常而得不償失——這要求團隊在選鏡像前完成必要的兼容性驗證。 - 多階段構(gòu)建的核心價值不在于減少層數(shù)，而在于“運行時不攜帶構(gòu)建時依賴”。這擊穿了一個常見誤區(qū)：以為把多個 RUN 命令用 && 串成一層就算優(yōu)化。事實上，即便在單層刪除了文件，下層依然可見，鏡像體積和服務(wù)攻擊面都不會真正縮小。只有通過多階段，讓最終鏡像根本不含編譯器、包管理器、源碼等，才能實現(xiàn)實質(zhì)瘦身。 - 緩存清理不是一次性動作，而需要納入 CI/CD 流水線的固定步驟。案例中可見，每次構(gòu)建產(chǎn)生的中間鏡像和懸虛層如果不主動清理，幾天內(nèi)就能讓開發(fā)服務(wù)器磁盤告急。建議在流水線末尾添加 docker system prune -f --filter "until=72h" 并給鏡像打上有意義的標(biāo)簽，避免大量 鏡像堆積。實踐中，團隊更應(yīng)在構(gòu)建前就用 .dockerignore 把 .git、node_modules、測試報告等無用文件排除，從源頭減少構(gòu)建上下文的傳輸量和層大小。

這兩個實戰(zhàn)案例不是終點。對于 Go 應(yīng)用，用 FROM scratch 并僅拷貝二進制，能將鏡像從 800 MB 級別的 golang 基礎(chǔ)鏡像壓縮到 10 MB 以下；對于 Python，利用虛擬環(huán)境與多階段拷貝同樣可以避開 pip 緩存的增重陷阱。多階段構(gòu)建配合精簡基礎(chǔ)鏡像和合理的 .dockerignore 配置，已經(jīng)成為容器化部署中“默認應(yīng)該出現(xiàn)”的實踐，而不是可選的高階玩法。

六、常見問題與注意事項

在實際落地多階段構(gòu)建和緩存清理的過程中，有幾個高頻問題值得專門拿出來講清楚。它們往往不是技術(shù)原理有多復(fù)雜，而是開發(fā)者對 Docker 層機制和構(gòu)建上下文的預(yù)期與真實行為之間存在落差。

1. 緩存失效怎么辦？

緩存失效最直接的觸發(fā)因素有兩個：Dockerfile 中某條指令本身發(fā)生了變化，或者該指令的上下文（如被 COPY 的文件）發(fā)生了任何比特級的改動。很多團隊的第一反應(yīng)是加 --no-cache 強制全量重建，但這是“把問題埋了”的做法——構(gòu)建時間會從 30 秒膨脹到 5 分鐘以上，而且不會清除已有的臟歷史層。

更實際的排查與修復(fù)路徑分三步。第一步，順序檢查指令依賴鏈：如果 COPY package.json 層之后的所有層都未命中，那多半是依賴清單真的變了，緩存不命中是合理的，應(yīng)接受它。第二步，留意那些在構(gòu)建過程中引入變化源的操作，例如 RUN curl 拉取外部腳本或 apt-get update，這些指令天然不具備冪等性，應(yīng)盡可能用版本固定的基礎(chǔ)鏡像和哈希校驗鎖定，或者將這類步驟放在多階段構(gòu)建的中間階段，讓最終鏡像不受其層緩存影響。第三步，確認 .dockerignore 是否把 node_modules、.git、本地日志等無關(guān)文件排除干凈——一個常見的場景是開發(fā)者本地的 editor 臨時文件進入上下文，導(dǎo)致 COPY . . 的哈希變動，無效地拆毀后續(xù)所有緩存。做完這一步基本可以消除 80% 以上的“玄學(xué)”緩存失效。

對于 CI 環(huán)境，推薦在流水線中顯式保留 --cache-from 拉取遠程鏡像作為緩存源，并配合 --build-arg BUILDKIT_INLINE_CACHE=1 將緩存元數(shù)據(jù)寫入鏡像。這樣即使在全新的執(zhí)行機上，也能復(fù)用上一次構(gòu)建的層，顯著控制構(gòu)建時間。

2. 是否所有項目都適用？

多階段構(gòu)建不是銀彈。絕大多數(shù)編譯型語言（Go、Rust、Java、C/C++）和需要構(gòu)建工具鏈的 Node.js 前端項目都能從中獲得明顯的體積瘦身——一個典型的 React 應(yīng)用，在多階段構(gòu)建后，鏡像體積可以從 1.2 GB 降至 80 MB 左右，壓縮后傳輸量減少 90% 以上。但這是有前提的：你的最終運行產(chǎn)物必須能脫離構(gòu)建工具獨立存在。

對于直接解釋執(zhí)行、不產(chǎn)生獨立二進制產(chǎn)物的項目（比如純 Python 腳本、PHP 應(yīng)用、Ruby 項目），多階段構(gòu)建的收益會急劇縮小。這類場景下，源代碼和解釋器必須共存，構(gòu)建階段的存在意義更多是安裝依賴和可能需要的編譯擴展，然后你需要把整個虛擬環(huán)境或 vendor 目錄連同解釋器一起拷貝到最終鏡像。此時鏡像瘦身的核心杠桿轉(zhuǎn)移到了基礎(chǔ)鏡像選擇：把 python:3.11 換成 python:3.11-slim 就能減少約 150 MB，換成 python:3.11-alpine 還能再砍掉 100 MB。但同樣要警惕 Alpine 的 musl libc 兼容性陷阱，比如 Pandas、NumPy 等科學(xué)計算庫在 Alpine 上的安裝耗時和 wheel 可用性就可能讓你得不償失。

另一個容易被忽略的盲區(qū)是依賴動態(tài)鏈接的舊系統(tǒng)。某些遺留的 C++ 服務(wù)依賴特定版本的 glibc 和系統(tǒng)動態(tài)庫，強行使用 distroless/static 或 scratch 會造成運行時段錯誤。這類項目更適合從 debian:slim 這類“中間路線”出發(fā)，通過多階段構(gòu)建剝離編譯依賴，而非追求極致體積。

3. 其他瘦身工具推薦

除了多階段構(gòu)建，還有幾個輕量級的開源工具可以在 CI 流水線中作為補充手段，而不侵入 Dockerfile 本身的邏輯。

第一個是 Dive，它用于分析鏡像每一層的內(nèi)容、大小變化以及可能存在的浪費空間。一個典型場景是，你發(fā)現(xiàn)某層增加了幾十 MB 大小，但實際有效文件只有幾 MB，Dive 直接標(biāo)注出哪些文件是被后續(xù)層刪除的重復(fù)數(shù)據(jù)。在代碼審閱階段跑一次 Dive，可有效防止人工引入的層膨脹。

第二個是 DockerSlim，它更進一步，通過對鏡像進行靜態(tài)和動態(tài)分析，自動找出應(yīng)用實際不需要的文件和庫，生成一個“最小化”鏡像。對于一些沒精力重寫 Dockerfile 的歷史遺留項目，DockerSlim 能在幾分鐘內(nèi)把鏡像壓縮到原來的 1/5 甚至 1/10，代價是需要自行驗證功能完整性——它是一個事后補充手段，替代不了構(gòu)建階段的架構(gòu)優(yōu)化。

最后必須強調(diào)，工具只是輔助，理解鏡像層原理并定期執(zhí)行 docker system prune 類的主動清理才是根本。在生產(chǎn)環(huán)境，通常建議在每日構(gòu)建的末尾掛接一條 docker system prune -f --filter "until=72h"，并配合標(biāo)簽策略確保只清理真正的過期緩存。懸虛鏡像 占比一旦超過總鏡像數(shù)的 30%，往往預(yù)示著團隊缺乏一致的標(biāo)記和回收規(guī)范，這時候問題不在工具，在流程。