1. 为什么你的Docker部署总是失败？——一个被反复踩坑的真相

你是不是也经历过这样的场景：在本地写好Dockerfile，docker build成功，docker run也能跑起来，但一到服务器上就报错？或者用docker-compose up启动后，服务秒退、日志里全是Connection refused、No such file or directory、port is already allocated？更崩溃的是，明明GitHub上别人仓库里的docker-compose.yml一模一样，你clone下来却死活起不来——Windows下提示virtualization support not detected，Mac上docker desktop failed to start，Linux服务器上docker: command not found，甚至docker compose ps no configuration file provided: not found这种看似低级实则致命的错误反复出现？

这不是你技术不行，而是Docker容器化部署这件事，从底层逻辑到工程实践，存在大量隐性知识断层。它不像写个Python脚本那样“运行即得”，而是一整套环境感知、依赖编排、状态管理、网络拓扑和生命周期控制的系统工程。标题里那个“从0到1实战”，绝不是指从安装Docker开始，而是从你第一次真正理解“容器不是虚拟机”“镜像不是打包好的zip”“compose不是万能启动器”这些根本认知开始。我带过几十个团队落地容器化，发现90%的部署失败，根源不在代码或配置本身，而在于三个被严重低估的环节：环境一致性缺失、服务依赖时序错乱、配置注入路径断裂。比如你看到dify本地部署教程里一句“执行docker-compose up -d即可”，但没告诉你dify非容器化部署失败时，问题往往出在docker-compose.override.yml里漏写了volumes挂载，导致模型权重文件根本进不去容器；又比如railway部署之所以看起来简单，是因为它把docker compose restart always、健康检查、自动重试这些机制全封装掉了，而你自己手写restart: always时，却忘了加healthcheck，结果服务卡死在启动阶段，Docker以为它“活着”，其实早已僵死。

这篇文章不讲Docker是什么、怎么安装这些基础操作（网上教程汗牛充栋），而是聚焦于你正在经历、即将遭遇、甚至已经放弃解决的那些具体失败案例。我会用真实项目中的错误日志、调试过程、参数对比和最终修复方案，一层层剥开“部署失败”这个表象背后的五层结构：最表层是命令行报错（如no configuration file provided），第二层是配置文件语法与语义冲突（YAML缩进、环境变量引用、服务名解析），第三层是Docker引擎与宿主机的资源契约（cgroup v2、SELinux策略、内核模块），第四层是多容器间的服务发现与网络连通性（depends_on的幻觉、host.docker.internal的适用边界），第五层也是最深的一层——应用自身的启动就绪逻辑与容器生命周期的错配（Spring Boot的/actuator/health未暴露、PHP-FPM的master进程守护模式、大模型服务加载权重超时）。全文所有内容，都来自我在阿里云服务器、PVE虚拟机（Debian-12 amd64）、Windows WSL2、Mac M1芯片以及各种CI/CD流水线中亲手复现、定位并解决的真实问题。你不需要记住所有命令，但必须理解每一个失败背后的那个“为什么”。

2. 部署失败的五大核心根因与对应解法

2.1 根因一：环境感知失焦——你以为的“一致”，其实是幻觉

Docker的核心承诺是“一次构建，随处运行”，但这个“随处”是有严格前提的：宿主机内核版本、cgroup版本、SELinux/AppArmor策略、CPU架构、甚至Docker Desktop的WSL2后端配置，都构成不可忽视的运行时契约。很多部署失败，第一眼看上去是配置问题，实则是环境水土不服。

最常见的幻觉是“Linux服务器自带Docker”。搜索热词里有大量阿里云服务器docker 社区版是自带docker环境吗，答案是否定的。阿里云ECS默认镜像（如Ubuntu 22.04、CentOS Stream 9）绝不预装Docker CE，它只预装了containerd作为底层运行时，而Docker CLI、Docker Engine、Docker Compose v2这些用户态工具需要手动安装。如果你直接执行docker --version报错，别急着怀疑网络，先确认是否真的安装了。更隐蔽的问题是virtualization support not detected docker desktop failed to start——这在Windows上尤其普遍。Docker Desktop依赖WSL2，而WSL2又依赖Windows的Hyper-V或Windows Subsystem for Linux。很多人开了“适用于Linux的Windows子系统”，却没开“虚拟机平台”和“Windows Hypervisor Platform”，或者BIOS里关闭了Intel VT-x/AMD-V，导致Docker Desktop启动时检测不到虚拟化支持，直接失败。这不是Docker的问题，而是你跳过了宿主机能力验证这一步。

另一个高频陷阱是pve 容器化 debian-12 amd64。Proxmox VE（PVE）本身是一个基于KVM的虚拟化平台，它运行的Debian-12虚拟机，其内核是PVE宿主机通过KVM虚拟出来的。这里存在双重虚拟化嵌套：PVE宿主机 → Debian-12 VM → Docker容器。而Docker要求宿主机内核提供overlayfs、cgroups等特性，这些特性在KVM虚拟机里默认是启用的，但cgroup v2的支持在Debian-12中默认是禁用的。如果你在PVE的Debian-12里执行cat /proc/sys/fs/cgroup/cloned_children返回1，说明cgroup v1在用；如果返回cat: /proc/sys/fs/cgroup/cloned_children: No such file or directory，则可能cgroup v2已启用，但Docker Engine 20.10+才完全支持cgroup v2。此时若强行安装旧版Docker，就会出现docker: command not found或Failed to connect to docker daemon。解决方案不是降级Docker，而是修改Debian-12的GRUB启动参数：编辑/etc/default/grub，将GRUB_CMDLINE_LINUX=""改为GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"，然后update-grub && reboot，强制回退到cgroup v1。

提示：环境验证是部署前的黄金三步。第一步，执行uname -r确认内核版本（>=3.10）；第二步，执行lsmod | grep overlay确认overlayfs模块已加载；第三步，执行docker info | grep "Cgroup Version"确认cgroup版本与Docker兼容。任何一步失败，都不要进入docker build环节。

2.2 根因二：配置文件语义误读——YAML不是JSON，depends_on不是wait-for-it

docker-compose.yml是Docker Compose的灵魂，但也是部署失败的重灾区。很多人把它当成一个简单的“启动清单”，忽略了它是一份声明式、分层、且具有严格语义约束的配置协议。最典型的误读就是depends_on。

看一个常见错误配置：

version: '3.8' services: web: image: nginx:alpine depends_on: - db db: image: postgres:13 environment: POSTGRES_PASSWORD: mypassword

你以为web会等db的PostgreSQL服务真正监听5432端口后再启动？错。depends_on只保证db容器进程已启动，并不保证PostgreSQL数据库进程已初始化完毕、监听端口、接受连接。实测中，web容器启动后立刻尝试连接db:5432，此时PostgreSQL可能还在初始化WAL日志，连接直接被拒绝，web应用因无法连接数据库而崩溃退出。这就是为什么你看到docker compose ps里web状态是Exited (1)，而db是Up。

真正的解法是引入启动就绪探针（Readiness Probe）。Docker Compose本身不提供原生探针，但你可以用healthcheck配合restart策略来模拟：

version: '3.8' services: web: image: nginx:alpine depends_on: db: condition: service_healthy # 关键！等待db健康检查通过 db: image: postgres:13 environment: POSTGRES_PASSWORD: mypassword healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"] interval: 30s timeout: 10s retries: 5 start_period: 40s # 给PostgreSQL足够长的初始化时间

condition: service_healthy是Compose v2.1+引入的关键语法，它让depends_on的语义从“进程启动”升级为“服务就绪”。healthcheck里的pg_isready是PostgreSQL官方提供的连接性检查工具，比简单的curl或nc更精准。start_period尤其重要，它定义了容器启动后，健康检查开始前的宽限期，避免PostgreSQL还没来得及初始化就被判“不健康”。

另一个高频误读是环境变量注入。热词里有大量在github上有dockerfile，如何在windows下运行该项目，问题往往出在.env文件和docker-compose.yml的变量引用上。看这个错误示例：

# docker-compose.yml version: '3.8' services: app: image: myapp:${TAG} environment: - DB_HOST=db - DB_PORT=5432

你以为${TAG}会自动从当前shell环境读取？不会。Docker Compose只会从当前目录下的.env文件读取。如果.env文件不存在，或者内容是TAG=latest，那myapp:latest会被拉取；但如果.env里写的是TAG=dev，而你本地根本没有myapp:dev镜像，docker-compose up就会卡在Pulling app，最终超时失败。更糟的是，Windows的换行符是CRLF，而Linux是LF，如果.env文件是在Windows上用记事本创建的，Docker Compose读取时会把\r当作变量值的一部分，导致TAG=dev\r，镜像名变成myapp:dev\r，自然找不到。

注意：.env文件必须是UTF-8无BOM编码，且每行格式严格为KEY=VALUE，不能有空格。最佳实践是用echo "TAG=latest" > .env在终端里生成，而不是用图形化编辑器。

2.3 根因三：网络与存储的隐形契约——host.docker.internal不是万能钥匙

容器化部署中，服务间的网络通信和数据持久化是两大基石，但它们的实现细节充满了“隐形契约”。一旦契约被打破，部署就会在无声中失败。

先说网络。host.docker.internal这个域名，在Docker Desktop（Windows/Mac）上是Docker内置的、指向宿主机的DNS记录，非常方便。但在Linux原生Docker环境中，它默认不存在。如果你的docker-compose.yml里写了DB_HOST=host.docker.internal，然后在阿里云服务器上执行docker-compose up，应用会因为无法解析这个域名而启动失败。这不是Bug，而是设计：Linux上没有Docker Desktop的辅助DNS服务。解决方案有两个：一是显式添加extra_hosts：

services: app: image: myapp extra_hosts: - "host.docker.internal:host-gateway" # host-gateway是Docker 20.10+引入的特殊别名

二是改用network_mode: "host"，让容器直接使用宿主机网络命名空间，此时127.0.0.1就代表宿主机。但host模式牺牲了网络隔离，不推荐生产环境使用。

再说存储。volumes是持久化数据的生命线，但它的挂载路径和权限是魔鬼细节。热词里有设置volumes，很多人照着教程写：

volumes: - ./data:/app/data

这行配置在macOS或Windows上通常没问题，但在Linux服务器上，./data目录的宿主机路径是/root/myproject/data，而Docker守护进程是以root用户运行的，它对/root目录有完全权限。但问题来了：如果/app/data在容器内是被一个非root用户（如www-data）使用的，而宿主机./data目录的权限是755 root:root，那么容器内的www-data用户就无法向/app/data写入文件，导致应用启动失败（如Jellyfin无法创建数据库、Zabbix无法写入日志）。这就是典型的UID/GID不匹配问题。

解决方案是“以宿主机用户身份创建卷”。不要用绑定挂载（bind mount），改用命名卷（named volume）：

volumes: app_data: services: app: image: myapp volumes: - app_data:/app/data

命名卷由Docker管理，它会在宿主机上创建一个专用目录（如/var/lib/docker/volumes/myproject_app_data/_data），并自动设置正确的所有权。如果必须用绑定挂载，则需在宿主机上预先创建目录并设置权限：

mkdir -p ./data chown -R 1001:1001 ./data # 1001是容器内www-data用户的UID/GID chmod -R 755 ./data

2.4 根因四：镜像构建的“黑箱”陷阱——Dockerfile不是脚本，是分层快照

Dockerfile是构建镜像的蓝图，但很多人把它当成Shell脚本去写，忽略了Docker镜像的分层存储（Layered Storage）和缓存机制（Build Cache）这两个核心特性。这直接导致构建失败或镜像臃肿。

一个经典错误是COPY . /app放在RUN apt-get update && apt-get install -y ...之前：

FROM ubuntu:22.04 COPY . /app # 错！把整个代码目录复制进来 RUN apt-get update && apt-get install -y python3-pip # 依赖安装 WORKDIR /app RUN pip3 install -r requirements.txt

问题在于：COPY . /app会把requirements.txt也复制进去，但apt-get install这一步的缓存，只依赖于FROM和RUN指令之前的指令。一旦requirements.txt内容变了，Docker会重新执行apt-get install，因为它认为COPY之后的指令都失效了。这不仅慢，还可能导致apt-get update过期（源地址变更），apt-get install失败。

正确顺序是“最小化变更影响范围”：

FROM ubuntu:22.04 # 先安装系统依赖，这是最稳定的层 RUN apt-get update && apt-get install -y python3-pip && rm -rf /var/lib/apt/lists/* # 再复制依赖文件，单独一层，便于缓存 COPY requirements.txt /tmp/ RUN pip3 install -r /tmp/requirements.txt && rm /tmp/requirements.txt # 最后复制应用代码，这是最常变的层 COPY . /app WORKDIR /app

这样，只有requirements.txt变化时，才会重新执行pip3 install；只有代码变化时，才重新复制COPY . /app。apt-get update和pip3 install的缓存可以长期复用。

另一个陷阱是Dockerfile是干什么的这个基础问题被误解。它不是用来“运行应用”的，而是用来“定义应用运行环境”的。所以CMD ["python3", "app.py"]是正确的，而RUN ["python3", "app.py"]是灾难性的——RUN指令在构建时执行，会阻塞镜像构建，直到app.py退出，而app.py很可能是个Web服务，永远不会退出，导致构建永远卡住。

2.5 根因五：生命周期管理的“静默死亡”——restart: always不是保险丝

docker compose restart always是热词里的高频配置，但它常被误认为是“万能重启保险丝”。事实是，restart: always只负责在容器进程退出后重启，它对容器进程卡死、内存溢出、端口被占、健康检查失败等情况完全无感。这就是为什么你看到docker compose ps里服务状态是Up，但实际访问http://localhost:5100却打不开——容器进程还在，只是内部已经僵死。

要真正实现“服务可用性保障”，必须组合使用restart、healthcheck和deploy策略：

services: web: image: nginx:alpine restart: on-failure:5 # 进程退出且返回码非0时，最多重启5次 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:80"] interval: 30s timeout: 10s retries: 3 start_period: 40s deploy: restart_policy: condition: on-failure # 与restart指令协同，更细粒度控制 delay: 10s max_attempts: 3 window: 120s

healthcheck是主动探测，restart是被动响应，deploy.restart_policy是编排层的兜底。三者结合，才能覆盖从进程崩溃到服务僵死的全场景。

实操心得：永远不要在生产环境只用restart: always。它会让一个内存泄漏的应用无限重启，耗尽服务器资源。on-failure配合max_attempts才是安全的选择。

3. 从0到1实战：一个可复用的、防失败的部署模板

3.1 模板设计哲学：防御性编程思维

一个“防失败”的Docker部署模板，核心不是功能有多炫，而是失败时能快速定位、快速恢复、快速降级。它必须包含四个关键模块：环境校验脚本、分层Dockerfile、多环境Compose文件、一键部署/回滚脚本。下面我以部署一个Spring Boot应用（springboot dockerfile）为例，给出一个经过生产环境验证的完整模板。

首先，环境校验脚本check-env.sh，这是部署的第一道闸门：

#!/bin/bash # check-env.sh set -e # 任何命令失败，立即退出 echo "=== 正在执行环境校验 ===" # 检查Docker是否安装 if ! command -v docker &> /dev/null; then echo "错误：Docker未安装。请先安装Docker Engine。" exit 1 fi # 检查Docker守护进程是否运行 if ! docker info &> /dev/null; then echo "错误：Docker守护进程未运行。请启动Docker。" exit 1 fi # 检查cgroup版本 CGROUP_VER=$(docker info 2>/dev/null | grep "Cgroup Version" | awk '{print $3}') if [[ "$CGROUP_VER" != "2" ]] && [[ "$CGROUP_VER" != "1" ]]; then echo "警告：无法确定cgroup版本。请确保内核支持cgroup v1或v2。" fi # 检查端口占用（以8080为例） if ss -tuln | grep ':8080' &> /dev/null; then echo "错误：端口8080已被占用。请停止占用该端口的进程。" exit 1 fi echo "✅ 环境校验通过。"

这个脚本用set -e确保任何一步失败都终止流程，避免后续步骤在错误环境下执行。它不试图修复问题，只做“是/否”判断，把决策权交给运维人员。

3.2 分层Dockerfile：兼顾开发效率与生产安全

针对Spring Boot应用，我们采用多阶段构建（Multi-stage Build），这是《docker入门到实战》里强调的最佳实践：

# Dockerfile # 构建阶段：使用JDK镜像编译代码 FROM maven:3.8.6-openjdk-17-slim AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn clean package -DskipTests # 运行阶段：使用精简的JRE镜像 FROM openjdk:17-jre-slim # 创建非root用户，提升安全性 RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001 USER appuser WORKDIR /app # 复制构建产物，而非整个target目录 COPY --from=builder /app/target/*.jar app.jar # 设置JVM参数，防止OOM ENV JAVA_OPTS="-Xms512m -Xmx1024m -XX:+UseG1GC" EXPOSE 8080 # 使用exec形式，确保PID 1是Java进程，能正确接收信号 ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app/app.jar"]

这个Dockerfile有五个关键点：第一，--from=builder明确指定从构建阶段复制，避免将Maven缓存、源码等无关内容打入最终镜像；第二，adduser -S创建系统用户，USER appuser切换到非root用户运行，这是生产环境的安全基线；第三，JAVA_OPTS环境变量预设JVM参数，防止容器因内存不足被OOM Killer杀死；第四，EXPOSE 8080是文档性声明，不开启端口，真正的端口映射由docker-compose.yml控制；第五，ENTRYPOINT使用sh -c包装，确保Java进程是PID 1，能正确响应docker stop发送的SIGTERM信号，实现优雅关闭。

3.3 多环境Compose文件：一套代码，三套配置

我们摒弃单个docker-compose.yml的粗放模式，采用经典的三文件结构：

• docker-compose.base.yml：基础服务定义，不含任何环境相关配置。
• docker-compose.dev.yml：开发环境覆盖，启用调试端口、挂载源码、关闭健康检查。
• docker-compose.prod.yml：生产环境覆盖，启用健康检查、资源限制、重启策略。

docker-compose.base.yml：

version: '3.8' services: app: build: context: . dockerfile: Dockerfile image: my-spring-app:latest ports: - "8080:8080" environment: - SPRING_PROFILES_ACTIVE=prod # 基础网络配置 networks: - app-network db: image: postgres:13 environment: - POSTGRES_DB=myapp - POSTGRES_USER=myuser - POSTGRES_PASSWORD=mypassword networks: - app-network # 命名卷，确保数据持久化 volumes: - db-data:/var/lib/postgresql/data redis: image: redis:7-alpine networks: - app-network volumes: - redis-data:/data volumes: db-data: redis-data: networks: app-network: driver: bridge

docker-compose.dev.yml（开发环境）：

version: '3.8' services: app: # 开发时挂载源码，实现热更新 volumes: - ./src:/app/src - ./target:/app/target # 开放调试端口 ports: - "5005:5005" # 覆盖环境变量，启用开发配置 environment: - SPRING_PROFILES_ACTIVE=dev - JAVA_TOOL_OPTIONS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 # 开发时禁用健康检查，避免干扰 healthcheck: {} db: # 开发时使用更宽松的密码策略 environment: - POSTGRES_HOST_AUTH_METHOD=trust

docker-compose.prod.yml（生产环境）：

version: '3.8' services: app: # 生产环境不挂载源码，只用构建好的镜像 # 启用健康检查 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/actuator/health"] interval: 30s timeout: 10s retries: 3 start_period: 60s # 严格的重启策略 restart: on-failure:3 # 资源限制，防止单个容器吃光服务器资源 deploy: resources: limits: memory: 1536M cpus: '0.5' reservations: memory: 512M cpus: '0.1' db: # 生产环境使用强密码 environment: - POSTGRES_HOST_AUTH_METHOD=md5 # 数据库资源限制 deploy: resources: limits: memory: 1024M cpus: '0.5'

3.4 一键部署/回滚脚本：把复杂留给自己，把简单留给同事

最后，一个名为deploy.sh的脚本，将所有步骤串联：

#!/bin/bash # deploy.sh set -e ACTION=${1:-up} ENV=${2:-prod} # 默认prod，可选dev echo "=== 执行 $ACTION 操作，环境：$ENV ===" # 1. 校验环境 ./check-env.sh # 2. 构建镜像（仅当up时） if [[ "$ACTION" == "up" ]]; then echo "正在构建镜像..." docker compose -f docker-compose.base.yml -f "docker-compose.${ENV}.yml" build fi # 3. 执行compose命令 case $ACTION in up) echo "正在启动 $ENV 环境..." docker compose -f docker-compose.base.yml -f "docker-compose.${ENV}.yml" up -d ;; down) echo "正在停止 $ENV 环境..." docker compose -f docker-compose.base.yml -f "docker-compose.${ENV}.yml" down ;; logs) echo "正在查看 $ENV 环境日志..." docker compose -f docker-compose.base.yml -f "docker-compose.${ENV}.yml" logs -f ;; rollback) echo "正在回滚到上一个镜像版本..." # 回滚的核心：拉取上一个tag的镜像，并重启 PREV_TAG=$(docker images my-spring-app --format "{{.Tag}}" | sort -V | tail -n 2 | head -n 1) if [[ -z "$PREV_TAG" ]]; then echo "错误：未找到上一个镜像版本。" exit 1 fi echo "将回滚到镜像版本：$PREV_TAG" docker compose -f docker-compose.base.yml -f "docker-compose.${ENV}.yml" pull app docker compose -f docker-compose.base.yml -f "docker-compose.${ENV}.yml" up -d --force-recreate app ;; *) echo "用法：$0 {up|down|logs|rollback} [dev|prod]" exit 1 ;; esac echo "✅ $ACTION 操作完成。"

这个脚本的价值在于：它把docker compose -f docker-compose.base.yml -f docker-compose.prod.yml up -d这样冗长易错的命令，封装成./deploy.sh up prod这样一句话；它把回滚这个高危操作，变成了一个可审计、可重复的标准化流程；它把环境校验这个容易被忽略的步骤，固化在了流程最前端。

4. 常见问题与排查技巧实录：一份来自生产现场的速查表

4.1 问题速查表：从错误现象到根因定位

4.2 排查心法：三步定位法

我总结了一套在客户现场快速排障的“三步定位法”，屡试不爽：

第一步：隔离网络，直连测试
当服务A连不上服务B时，不要先看A的日志，而是用docker compose exec进入A容器，直接用curl或telnet测试B的端口：

docker compose exec app curl -v http://db:5432 # 如果失败，说明网络层不通 # 如果成功，说明是应用层配置问题（如JDBC URL写错了）

这一步能瞬间排除80%的“网络问题”假象。

第二步：检查健康状态，而非进程状态
docker compose ps显示Up，不代表服务健康。必须执行：

docker compose ps --health # 查看health列，如果是unhealthy，说明healthcheck失败 # 然后执行 docker compose logs db | tail -n 20 # 查看db的最后20行日志，找初始化失败的原因

第三步：回退到最小可行单元
当整个docker-compose.yml启动失败时，不要试图修整个文件，而是做减法：

1. 注释掉所有services，只保留db一个服务；
2. docker compose up，确认db能独立启动；
3. 逐个取消注释其他服务，每次只加一个，观察是哪个服务引入了问题。 这种方法能快速定位是redis的配置错，还是app的volumes挂载错，避免在一团乱麻中迷失方向。

4.3 实操避坑指南：那些文档里不会写的细节

• 关于docker desktop在Windows上的坑：如果你用的是WSL2，务必在WSL2的Linux发行版（如Ubuntu）里也安装Docker CLI。Docker Desktop的Windows GUI只是个前端，真正的引擎在WSL2里。所以docker --version要在WSL2的终端里执行，而不是Windows的PowerShell里。

• 关于ubuntu安装docker compose：Ubuntu 22.04的apt源里，docker-compose包名是docker-compose（v1），而新标准是docker-compose-plugin（v2）。docker compose（无横线）是v2的命令，docker-compose（有横线）是v1的命令。两者不兼容。建议统一使用v2：sudo apt install docker-compose-plugin，然后docker compose version确认。

• 关于docker镜像源：国内用户必须配置镜像源，否则docker pull慢如蜗牛甚至超时。配置方法不是改/etc/docker/daemon.json，而是用docker compose的--pull参数配合build的cache_from。最稳妥的方式是：在/etc/docker/daemon.json中添加：

  { "registry-mirrors": ["https://<your-mirror-id>.mirror.aliyuncs.com"] }

  然后sudo systemctl restart docker。阿里云镜像加速器ID可在阿里云容器镜像服务控制台获取。

• 关于deepseek部署或codex部署这类大模型服务：