如果你搞過 Docker應該對這個畫面不陌生一條docker pull mysql:8.0命令敲下去進度條卡在Downloading [ ] 32.44MB/150MB半天不動最後還可能給你報一個deadline exceeded。這事情我前前後後折騰了兩年直到最近把整套環境重新整理了一遍才真正體會到那種“命令敲下去鏡像就到位”的順暢感。“毫秒鏡像”是我給這套優化方案起的代號聽起來有點誇張但實際用下來很多場景下並不算誇張鏡像層如果已經緩存在本地重複拉取的耗時是以毫秒計的基礎鏡像小、鏈路質量正常的時候docker pull完成也在百毫秒級別。真正解決問題的核心不是什麼祕密武器而是把 Docker 官方支持的那套鏡像加速體系用“正規軍”的方式完整落地。這篇文章我會把這套方案的原理、配置、實操過程和踩坑記錄都攤開講想要告別“拉個鏡像像下片一樣煎熬”的朋友照著做即可。1. 項目概覽與方案選型為什麼我執意走“正規軍”路線1.1 “毫秒鏡像”到底在解決什麼問題先說結論“毫秒鏡像”不是一個需要安裝的軟件也不是某個神祕的加速工具它是一套基於 Docker 官方機制搭建的鏡像加速體系。整個方案的目標只有一個——讓任何一臺服務器上執行 docker pull都儘可能快地把需要的鏡像拿回來並且這個速度是可預期的、可複用的、可維護的。我把這套體系拆成了四個部分第一部分是給 Docker 守護進程配置規範的鏡像加速器registry mirror。第二部分是按需部署內網的私有鏡像倉庫用於團隊級的分發和緩存。第三部分是優化鏡像本身的體積從源頭上降低網絡傳輸的數據量。第四部分是調整 Docker 自身的並發和緩存參數把現有帶寬喫滿。這四件事單獨拿出來都不復雜但很多教程只講第一件而且講得特別粗糙比如隨手丟給你幾個加速地址也不解釋原理。結果就是今天能用明天失效這臺機器行換一臺機器又不行。我這篇的思路是把四件事串成一個完整的閉環先用加速器解決“從哪裏下”的問題再用私有倉庫解決“團隊怎麼共享緩存”的問題接著用鏡像瘦身解決“數據量能不能更小”的問題最後用並發參數解決“帶寬使用率”的問題。四步走完你才能得到真正的“秒下”體驗而不是碰運氣。1.2 為什麼默認拉鏡像像“龜速”不少人把拉鏡像慢簡單歸結為一句“網絡不好”但這個歸因太籠統了。我實際排查下來影響 docker pull 速度的因素至少有四個。第一是倉庫服務器的位置和鏈路質量。Docker 默認的官方鏡像倉庫節點訪問起來延遲高、可用性波動大很多時候就是“連接能建立但數據傳輸極慢”。第二是鏡像本身的結構。一個鏡像由多個只讀層layer組成Docker 需要把每一層都完整下載層數越多、每一層越大總耗時自然越長。第三是並發能力。Docker 默認的並發下載數不高如果你不主動調整它不會自動把帶寬跑滿。第四是緩存命中率。如果你每次拉鏡像都從零開始那麼一切內容都需要重新下載但有緩存時只需要下載缺失層速度會直線上升。把這四個因素拆開之後你就會發現優化其實是有清晰著力點的。“毫秒鏡像”這套方案本質上就是針對這四個因素逐一做手術。如果只知道“配置一個加速地址”那隻治了第一種病剩下三種病還在那兒改完之後體感依然不理想。1.3 備選路線不少為什麼“正規軍”勝出圈裏解決“拉鏡像慢”的辦法流傳過很多種但在我看來真正值得長期投入的只有官方支持的幾條路線。所謂“正規軍”我指的是這些渠道Docker 官方文檔明確支持的 registry mirror 機制。雲廠商提供的容器鏡像加速器和容器鏡像服務。可自行搭建的 Docker Registry / Harbor 私有倉庫。基於 BuildKit 和 OCI 標準的構建緩存體系。這幾條路線的共同點是它們全部基於標準的 Registry HTTP API 和 OCI 分發規範不依賴任何私有協議也不需要對 Docker 客戶端做任何改動。換句話說你配置出來的環境換一個人、換一臺機器、換一個 CI 流水線都能按同樣的方法複製不會出現“在這臺機器上有效在另一臺就掛了”的玄學情況。而且這些渠道遇到問題時都有明確的排查路徑——要麼看 daemon 日誌要麼看倉庫端口誌要麼看網絡層的丟包和延遲出問題了有據可查。選擇“正規軍”還有另外一層現實考慮維護成本。Docker 的鏡像加速機制在官方文檔裏有完整說明雲廠商的加速服務會隨賬號長期存在私有倉庫的部署也屬於基礎運維的常規操作。這三樣東西的生命週期都很長不會因為某個個人項目停止維護而突然作廢。對於要長期運維的服務器來說方案的生命週期比一時的速度更重要。加速方式維護成本使用門檻適合場景公共 registry mirror低但公共地址會變遷極低改配置即可個人開發機雲廠商加速器極低綁定雲賬號低控制臺獲取地址已有雲主機的用戶內網 Registry / Harbor中需自己運維中需要部署服務團隊、企業、CI鏡像瘦身 BuildKit 緩存低和開發流程綁定低配合 Dockerfile 使用所有長期項目2. 鏡像拉取與加速的核心原理一次講透2.1 docker pull 在底層究竟做了什麼在配置加速器之前我建議你先搞懂一條 docker pull 命令的完整執行路徑否則出了問題都不知道該從哪個環節排查。簡化之後的流程是這樣Docker 守護進程dockerd根據你給出的鏡像名拼接出默認的 Registry 地址比如mysql:8.0會拼接成docker.io/library/mysql:8.0。守護進程請求 Registry 的 manifest 接口拿到這個鏡像的元數據裡面記錄了鏡像有哪些層、每一層的 digestsha256 摘要、大小等信息。守護進程把 manifest 裡列的層和本地已有的層做比對只下載本地缺失的層。每個缺失的層作為一個 HTTP 請求去 Registry 的 blob 接口下載多個層之間按照並發配置同時下載。所有層下載完成後Docker 會做完整性校驗按 digest 比對然後解壓、掛載到存儲驅動上生成一個可運行的容器文件系統。這個流程裏最耗時的環節幾乎永遠是第 4 步也就是層數據的傳輸。但容易被忽略的是第 3 步如果你本地已經有某個層Docker 是不會重新下載它的。這也解釋了為什麼 Docker 的“二次拉取”往往比“第一次拉取”快得多因為基礎層已經在本地只要下載新增層就行。理解了這個流程你就知道加速器到底加速了哪個環節它加速的是第 2 步和第 4 步也就是 manifest 的獲取和層數據的傳輸。至於第 3 步的本地比對Docker 是通過內容尋址存儲content-addressable storage完成的不管你在哪個倉庫拉過同一個層只要 digest 相同本地都能複用。2.2 registry mirror 是怎麼工作的registry mirror 的官方名稱叫“註冊表鏡像”它的本質是一個支持拉取緩存的標準 Registry 服務。你可以把它理解成一個“前置倉庫”當你在 Docker 配置裏指定了 mirror 地址後守護進程在拉取 Docker Hub 的官方鏡像時會先去問 mirror你有沒有這個鏡像如果有直接從 mirror 下載如果沒有mirror 會替你去 Docker Hub 拿一份回來存到自己的緩存裏再把數據轉交給你。這個機制最關鍵的一點在於mirror 本質上就是一個標準 Registry只是多了緩存回源的能力。所以 Docker 官方文檔裏說得很清楚registry-mirrors這個配置項只對 Docker Hub 的官方鏡像生效對於 ghcr.io、quay.io、gcr.io 這些第三方倉庫它是不會攔截的。很多人配置完加速器之後跑去拉 ghcr.io 上的鏡像發現還是慢就以為配置失靈了。其實這個預期就錯了第三方倉庫要走它們自己的加速方案或者通過私有倉庫做二次分發。另外還有一個容易誤解的點mirror 不影響 docker push。push 永遠是往你寫入的那個 Registry 推不會自動往 mirror 推。因此你在開源項目 CI 裏看到的那種“先配置 mirror 再 push 到 ghcr.io”的做法mirror 是幫不上忙的該慢還是慢。配置 mirror 的位置在/etc/docker/daemon.json的registry-mirrors數組可以同時配置多個。Docker 守護進程在拉取鏡像時會按照順序依次嘗試遇到一個成功的就停止如果第一個 mirror 請求超時它會嘗試下一個。所以 mirror 列表不是越多越好放兩個到三個質量較好的即可放太多反而會因為超時等待拉長整體耗時。2.3 除了加速器這幾個參數才是體感關鍵很多人只改registry-mirrors發現提速不明顯就以為方法沒用。實際上加速器解決的是“從哪裏下載”的問題但沒有解決“同時下載多少”和“本地處理快不快”的問題。我個人經驗裏下面這幾個參數的影響絲毫不亞於加速器。第一個是max-concurrent-downloads。這個參數控制 dockerd 同時下載的最大層數默認值是 3也就是說一個鏡像最多同時下載 3 個層。如果你的鏡像有 20 個層即使帶寬再好也只能 3 個 3 個地下。我一般會把它調到 6 或者 10具體看機器帶寬和磁盤性能。增加並發之後大鏡像的拉取耗時往往有肉眼可見的改善。第二個是max-concurrent-uploads。這個參數控制 push 時的並發上傳數默認是 5。如果你是做 CI 要頻繁推送鏡像到私有倉庫可以稍微調高到 10 以內但注意 upload 會佔用帶寬和 download 共享同一條鏈路需要權衡。第三個是存儲驅動。Docker 默認推薦使用 overlay2它的性能和整體表現比老的 devicemapper 好得多。如果某些老機器還在用 devicemapper層的寫入和解壓會非常慢拉完鏡像之後在本地Importing那一步能卡半天。這種情況下優先把存儲驅動遷移到 overlay2比調什麼加速器都管用。第四個是 BuildKit。如果你主要在構建鏡像而不是拉取現成鏡像建議打開 BuildKit。Docker 23 默認開啟低版本可以通過DOCKER_BUILDKIT1環境變量開啟。BuildKit 會為每一條構建指令生成帶內容尋址的緩存層重複構建時只要步驟沒有變化就秒出結果。它的緩存機制比舊的 builder 更可靠是很多項目“感覺構建變快”的真正功臣。到這一步你已經掌握了“原理”層面的全部關鍵點。下一步我們直接上手把這套體系在一臺全新服務器上完整搭出來。3. 實操從零配置一套“毫秒鏡像”環境3.1 準備階段確認版本與備份配置動手之前先確認三件事。第一你的 Docker 版本。舊版本的 Docker 對registry-mirrors的處理存在一些細微差異建議至少使用 20.10 以上版本Docker 23 或者 24 更為理想。第二確認daemon.json當前是否存在。第三也是最重要的如果你正在跑生產容器不要直接修改完就重啟先做好備份再把服務切到維護窗口執行重啟。確認 Docker 版本的命令docker version --format {{.Server.Version}}查看當前 daemon 配置cat /etc/docker/daemon.json 2/dev/null || echo 文件不存在從零開始如果文件存在而且已經有一堆配置千萬別直接覆蓋。先備份一份再動手sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak.$(date %Y%m%d%H%M%S)這段操作看起來很基礎但我在幫朋友排查問題時見過太多直接把daemon.json清空、導致 Docker 原有配置丟失的案例。尤其是那些通過 Docker 安裝腳本自動生成的daemon.json裡面往往還藏著日誌輪轉、存儲驅動等關鍵配置一旦覆蓋重啟後可能直接起不來。3.2 配置公共鏡像加速地址確認完基礎環境之後編輯daemon.json。一個最基本的配置長這樣{ registry-mirrors: [ https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com, https://mirror.baidubce.com ], max-concurrent-downloads: 6 }這裏我要特意強調一句我寫的這些地址僅供舉例公共加速器地址會因為各種原因變更你在實際項目裏最該用的是自己雲廠商控制臺裏提供的加速器地址。比如阿里雲的容器鏡像服務控制臺會為每個賬號生成一個形如https://xxxxxxxx.mirror.aliyuncs.com的專屬加速地址騰訊雲也有對應的加速域名。把雲廠商給你的專屬地址放在 mirror 列表第一位再把通用公共地址放在後面做兜底效果最理想。配置完成後先檢查 JSON 語法再重啟 Dockersudo docker info --format {{.RegistryMirrors}} sudo systemctl daemon-reload sudo systemctl restart docker sudo docker info | grep -A5 Registry Mirrors如果一切正常docker info的輸出裏會顯示你配置的 mirror 地址。接下來做一個最直接的驗證拉一個熱門鏡像並統計耗時time docker pull alpine:latest time docker pull mysql:8.0第一次拉可能因為要建立緩存而稍慢第二次再拉同一個鏡像耗時會急劇縮短因為分層已經緩存。我用這套配置實測過第二次拉 alpine 基本上在 100 毫秒到 300 毫秒之間這就算是用戶能直觀感受到的“毫秒鏡像”。還有一點要提醒如果你在daemon.json裏同時配置了insecure-registries用於 HTTP 協議的私有倉庫要注意數組語法不能寫錯。常見的錯誤是在 JSON 末尾多加一個逗號導致 dockerd 啟動失敗。重啟前先跑一下docker run hello-world或者查看日誌journalctl -u docker -n 50都比直接重啟再發現起不來要好。3.3 團隊級加速搭建內網 Registry 做緩存分發個人開發機用公共加速器就夠了但團隊場景有它的痛點幾十個開發同時拉一個新版本鏡像每個人都要從公共加速器下載一遍同樣的數據既浪費時間又浪費帶寬。這時候“正規軍”裏的最佳實踐是搭一個內網 Registry作為團隊的統一鏡像分發點。最小可用的方案是直接跑一個 Docker Registry 容器並開啓它的緩存回源能力。先準備存儲目錄sudo mkdir -p /data/docker-registry默認的 Registry 不會自動回源。要開啓代理緩存模式需要給它寫一份配置文件讓它知道上游倉庫是 docker.io。創建配置文件version: 0.1 storage: cache: blobdescriptor: inmemory filesystem: rootdirectory: /var/lib/registry proxy: remoteurl: https://registry-1.docker.io http: addr: :5000把配置掛載進容器並啟動sudo docker run -d \ -p 5000:5000 \ -v /data/docker-registry:/var/lib/registry \ -v /etc/docker-registry/config.yml:/etc/docker/registry/config.yml \ --name registry \ --restartalways \ registry:2這樣一來團隊成員只需要把daemon.json裏的registry-mirrors指向內網地址比如http://registry.internal:5000。因為它走 HTTP必須把對應地址加進insecure-registries。每次有人第一次拉某個鏡像時內網 Registry 會去 Docker Hub 回源並緩存之後所有人再拉同一個鏡像就直接命中內網緩存速度基本上是本地網絡的上限。企業裏如果鏡像數量很多通常會進一步換成 Harbor因為它帶有 Web UI、權限控制和更強的多倉庫複製能力。但如果你只是想解決“團隊拉一個熱門鏡像反覆下載”的問題一個帶緩存的 Registry 已經足夠用了。我自己在一個小型團隊項目裏跑了一年多內網拉 mysql、redis、nginx 這些高頻鏡像耗時基本都在一秒以內這個體驗是公共加速器給不了的。3.4 讓鏡像本身變輕從源頭減少傳輸量加速器解決了“在哪裏下載”內網倉庫解決了“下載一次大家共用”但還有一件事沒解決如果鏡像本身就有 2GB哪怕速度再快也是要實打實傳輸 2GB 數據的。所以第四步是優化鏡像體積。最常用的手段就是多階段構建。拿 Go 程序舉個例子傳統寫法會直接基於 golang 鏡像編譯但 golang 鏡像動輒幾百 MB多階段構建則是用 golang 鏡像做編譯階段最後把靜態二進制拷進一個輕量運行鏡像比如 alpineFROM golang:1.22 AS builder WORKDIR /app COPY . . RUN CGO_ENABLED0 GOOSlinux go build -o app . FROM alpine:3.20 WORKDIR /app COPY --frombuilder /app/app /app/app EXPOSE 8080 ENTRYPOINT [./app]這樣最終鏡像可能只有幾十 MB拉取耗時直接縮短一個數量級。對於 Java 項目可以在構建時合併鏡像層、清理無用緩存對於 Python 項目儘量選擇 slim 基礎鏡像而不是帶完整工具鏈的版本。很多時候你以為是“網絡慢”實際上是“鏡像太大了”。我做過一個粗略對比基礎鏡像壓縮後大致體積適合場景python:3.12約 50MB需要完整工具鏈時python:3.12-slim約 25MB一般 Web 服務首選node:20約 50MB前端構建、完整環境node:20-alpine約 30MB輕量運行時golang:1.22約 120MB編譯階段golang:1.22-alpine約 45MB編譯後運行當然選基礎鏡像不能只看體積還要兼顧 glibc、musl、調試工具是否可用等因素。但總體原則是一致的運行時不需要的編譯工具、調試器、包管理器緩存都不該出現在最終鏡像裏。鏡像瘦身不是強迫症患者的專利它就是鏡像拉取加速體系裏不可分割的一部分。4. 典型場景復現MySQL、Redis、ComfyUI 一次跑通4.1 MySQL 8.0加速後一鍵拉起我見過不少教程讓大家直接docker run -p 3306:3306 -e MYSQL_ROOT_PASSWORDxxx mysql:8.0這種跑法不是不能用但很難用於實際項目因為容器一刪數據就全沒了。正確做法是先準備一個持久化目錄再運行容器sudo mkdir -p /opt/mysql-data sudo docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDMyStrongPass123! \ -e TZAsia/Shanghai \ -v /opt/mysql-data:/var/lib/mysql \ mysql:8.0在配置了加速器之後第一次docker pull mysql:8.0的耗時會比裸環境減少一大截。如果是在內網 Registry 已經緩存過的環境後面每次新建 MySQL 容器基本是秒級。要注意的是生產環境裏建議直接在docker-compose.yml裏定義 MySQL 服務方便管理重啓策略、資源限制和健康檢查。加速器的作用是讓docker compose up -d拉鏡像那一步不再等待整個編排流程才能做到行雲流水。4.2 Redis 主從從拉取到複製配置一氣呵成Redis 主從的搭建涉及到網絡隔離和多容器通信正好適合演示 docker compose。先建一個目錄mkdir -p /opt/redis-cluster cd /opt/redis-cluster然後用 Compose 拉起主從services: redis-master: image: redis:7-alpine container_name: redis-master command: [redis-server, --appendonly, yes] ports: - 6379:6379 networks: - redis-net redis-slave: image: redis:7-alpine container_name: redis-slave command: [redis-server, --slaveof, redis-master, 6379] depends_on: - redis-master networks: - redis-net networks: redis-net: driver: bridge第一次執行docker compose up -d時需要拉redis:7-alpine。這個鏡像很小加速器配上之後通常在一兩秒內就能完成。我特意選了 alpine 版本而不是默認版本就是為了讓大家直觀看到“鏡像體積決定了拉取耗時”這個結論。RDB 快照、AOF 持久化和主從複製的驗證步驟和傳統部署沒有區別但在容器環境下反覆重建的體驗會順滑得多。4.3 資源型鏡像ComfyUI 一類的加速策略像 ComfyUI 這類 AI 繪圖工具的鏡像和 MySQL、Redis 有個非常大的不同它們往往自帶 CUDA 運行時、Python 依賴、模型文件鏡像體積動輒好幾個 GB。加再快的加速器也不可能把網速變成無限帶寬。對這種場景我推薦三層加速策略。第一層常規的 registry mirror 還是要配上確保鏡像分層下載的網絡路徑是優化的。第二層如果是在雲服務器上使用優先讓 Docker 在與鏡像源距離更近的機器上完成首次拉取然後用docker save把鏡像導出成 tar 包再通過內網傳輸到其他機器用docker load導入。這等於繞開了公共網絡的重複下載速度會快得多。# 在 A 機器拉取並導出 docker pull your-user/comfyui:latest docker save your-user/comfyui:latest -o comfyui.tar # 傳輸到 B 機器後導入 docker load -i comfyui.tar第三層如果是自己構建的鏡像把模型文件用外部卷掛載進去而不是烤進鏡像裏。模型文件有幾個 GB如果每次構建都打進鏡像構建、推送、拉取都是災難。把模型放到宿主機目錄通過-v或 Compose 的 volumes 掛載鏡像本身就能瘦一大圈重構速度、分發速度都能得到明顯提升。這個習慣我在大型模型項目上反覆吃過虧之後才養成現在覺得怎麼強調都不為過。5. 常見問題與排查技巧實錄方案講完了但實際操作中總會遇到各種“看似簡單、搞死人不償命”的問題。我在這套方案的落地過程中踩過不少坑把最典型的幾個整理成一份排查清單。5.1 daemon.json 改了沒生效最常見的原因有三個。第一是 JSON 語法錯誤哪怕多了個逗號dockerd 都會直接報錯。檢查辦法很簡單sudo dockerd --validate第二是修改的文件位置不對。daemon.json的默認路徑是/etc/docker/daemon.json但如果你用的是 Docker Desktop配置入口是在 GUI 的 Settings 裏手動改文件可能被覆蓋。Linux 服務器上安裝的只要確認路徑就行。第三是改完之後沒有正確重啓。很多人只執行了systemctl reload docker但 reload 對daemon.json裏的部分配置不生效必須用systemctl restart docker。重啓完之後記得用docker info確認 Registry Mirrors 已經加載。除了這些還有一個很隱蔽的坑如果你配置了多個 mirror而第一個 mirror 返回了連接錯誤Docker 會等第一個超時再去試第二個。這個超時等待往往沒有直觀報錯表現為拉鏡像“轉圈半天才開始下載”。遇到這種情況把不靠譜的地址從列表裏摘掉只留測試通過的通常就能恢復正常。5.2 加速地址失效或者變慢怎麼處理公共加速地址不是我配置一次就能一勞永逸的。很多地址因為運營策略調整會在一段時間後停止服務或者大幅降速。我的建議是定期做健康檢查檢查方式很簡單for url in https://docker.mirrors.ustc.edu.cn https://hub-mirror.c.163.com; do echo $url curl -sI $url/v2/ -o /dev/null -w HTTP %{http_code}, 連接耗時 %{time_connect}s, 總耗時 %{time_total}s\n --connect-timeout 5 done如果某個地址長時間無響應或者響應極慢就把它從 mirror 列表裏移除。如果所有公共地址都不理想最可靠的回退方案是回到雲廠商控制臺重新獲取最新的專屬加速地址。還有一個細節可以留意有些 mirror 地址對 HTTPS 證書有特殊要求如果 curl 測試報證書錯誤而你又搞不定證書問題直接換一個地址。5.3 並發調高之後機器反而響應慢了把max-concurrent-downloads從 3 調到 10拉鏡像確實會快但它不是沒有代價的。並發下載意味着同時有 10 個 HTTP 連接在寫磁盤內存和 IO 壓力都會上升。如果你是低配的雲服務器1核2G這種並發拉到 10 可能在拉大鏡像時把 CPU 或者磁盤 IO 打滿甚至影響同機上其他業務。這種情況下建議先從 6 開始試觀察一下拉鏡像時機器的 load average 和 iostat再決定要不要繼續調高。另外並發下載在內網倉庫場景的效果很可能不如公共網絡明顯因為內網帶寬大、延遲低瓶頸往往不在並發而在磁盤解壓。如果發現調高並發後拉鏡像耗時沒有明顯變化先別急著繼續調看看是不是存儲驅動或者磁盤性能的問題。5.4 已經配置好加速為什麼拉第三方倉庫還是慢這是一個非常高頻的認知誤區。registry-mirrors只服務於 Docker Hub 的官方鏡像。如果你要拉的是 ghcr.io、quay.io、gcr.io 上的鏡像mirror 完全不會介入。我見過不少團隊為此做了很多無用功最後才發現根本不是配置的問題。解決第三方倉庫慢的“正規軍”思路是要麼讓目標倉庫本身的訪問鏈路更好要麼把目標鏡像轉存到自己的私有倉庫裏。比如企業裏可以把常用的第三方鏡像先在網絡條件較好的節點用docker pull拉下來再 push 到內網 Harbor之後所有機器都從內網拉取。這個流程能用自動化腳本定期同步屬於比較標準的鏡像治理方案。這套方案我前前後後用了很長時間最大的體會是真正讓你告別“拉鏡像困境”的不是一個萬能地址而是一套能落地的完整流程。先用 mirror 把默認鏈路理順再靠內網倉庫解決共享緩存最後用鏡像瘦身和並發參數把細節補齊。如果你只是想快速解決拉 mysql、redis、nginx 這些常用鏡像太慢的問題做到 3.2 小節那一步就夠了如果是在團隊裏跑強烈建議把 3.3 的內網 Registry 也搭起來。鏡像加速這件事沒有捷徑但“正規軍”的每一步都能讓你少走彎路。