1. 项目概述：为什么要在Docker里搞开发？

“在Docker中进行开发”这个标题，乍一听可能有点反直觉。我们习惯了在本地装好Python、Node.js、Java，配好环境变量，然后打开IDE就开始写代码。为什么要把自己“关”进一个容器里？这不是自找麻烦吗？作为一个在多个项目里踩过坑、也尝过甜头的开发者，我得说，这恰恰是解决开发环境“玄学”问题的一剂良药。

想想这些场景：新同事入职，对着你写的“README.md”里一长串“先装这个，再配那个，注意版本是xx.xx”的步骤挠头，折腾一整天环境还没跑起来；你自己在Mac上跑得好好的服务，部署到Linux服务器上就各种报错；团队里有人用Windows，有人用macOS，还有用各种Linux发行版的，为了一个依赖库的编译问题能吵半天。这些问题的根源，都指向了环境不一致。Docker的核心价值，就是用容器技术将应用及其 完整的运行环境 （包括代码、运行时、系统工具、系统库和设置）打包成一个标准化的单元。在开发阶段使用它，意味着你为项目定义了一个 确定性的、可移植的、一次构建处处运行 的“开发沙箱”。

这不仅仅是“方便部署”那么简单。它意味着：

  • 环境隔离 ：每个项目都有自己的“小世界”，Python 2.7和Python 3.11可以井水不犯河水，Node 14和Node 18也能和平共处，再也不会因为全局包污染而头疼。
  • 快速搭建 ：新成员只需一条 docker-compose up 命令，就能获得一个和线上无限接近的、立即可用的开发环境，包括数据库、缓存、消息队列等所有依赖服务。
  • 复现问题 ：测试或用户报了一个Bug，你可以瞬间拉起一个和报错时一模一样的环境进行调试，而不是在本地猜“是不是我装的某个库版本不对”。
  • 跨平台一致性 ：无论你的宿主机是Windows、macOS还是Ubuntu，容器内部看到的都是统一的Linux环境（假设你用的是Linux容器），彻底告别“在我机器上好好的”这类问题。

所以，在Docker中进行开发，本质上是将 基础设施即代码 的理念前置到了开发环节。你的 Dockerfile 和 docker-compose.yml 就是开发环境的“源代码”，可以被版本管理、被评审、被复用。接下来，我们就深入拆解如何搭建并高效利用这个开发沙箱。

2. 核心思路与方案选型：定义你的开发容器

在Docker里开发，不是简单地把你的代码目录挂载进一个现成的官方镜像就跑。我们需要精心设计容器的构建和运行方式，在享受隔离性好处的同时，不能牺牲开发体验，比如代码热重载、实时调试、快速的依赖安装等。

2.1 开发模式 vs 生产模式

首先要明确一个关键区别： 开发容器 和 生产容器 的目标不同。

  • 生产容器 ：追求极致的镜像体积小、安全性高、运行稳定。通常使用多阶段构建，最终镜像只包含运行应用所必需的最精简内容。
  • 开发容器 ：追求便利性、可调试性和快速迭代。镜像体积可以稍大，里面需要包含编译工具、调试器、代码检查工具，甚至是你喜欢的 vim 或 zsh 配置。

因此，我们通常会为项目准备两个 Dockerfile ： Dockerfile.dev （用于开发）和 Dockerfile （用于生产）。或者，在一个 Dockerfile 中使用多阶段构建，并利用 target 参数来指定构建开发阶段。

2.2 镜像选择：基础镜像的权衡

选择基础镜像是第一步。以Python开发为例：

  • python:3.11-slim ：这是一个很好的 生产环境 基础选择。它基于Debian，比完整的 python:3.11 镜像小很多，只包含运行Python应用的必要系统包。
  • python:3.11 ：这是 开发环境 更合适的选择。它包含了 gcc , make 等编译工具，让你可以轻松地 pip install 那些需要编译C扩展的包（如 psycopg2 、 cryptography 等）。
  • python:3.11-buster (或 bullseye ) ：如果你想获得一个更完整的Debian系统环境，方便安装其他系统工具（如 curl , git , vim ），可以选择这个。

我的经验 ：对于团队开发，我强烈建议统一使用 python:3.11 作为开发基础镜像。虽然体积大一点（约1GB），但避免了每个人因为缺少编译工具而 pip install 失败，节省的沟通和排错成本远超那点磁盘空间。生产镜像则务必使用 slim 版本。

2.3 代码挂载：保持实时同步

开发的核心是写代码。我们肯定不想每次修改后都重新构建镜像。Docker的 绑定挂载 功能解决了这个问题。通过 -v 参数或将配置写入 docker-compose.yml ，我们可以把宿主机的项目目录直接挂载到容器内的对应路径。

# docker-compose.yml 片段
version: '3.8'
services:
  web:
    build:
      context: .
      dockerfile: Dockerfile.dev
    volumes:
      # 将当前目录挂载到容器的 /app 目录
      - .:/app
      # 可选的：挂载一个用于缓存依赖的卷，加速安装
      - pip-cache:/root/.cache/pip
    working_dir: /app
    command: python app.py

这样，你在宿主机上用IDE修改代码，容器内运行的应用能立刻看到变化。对于支持热重载的框架（如Flask debug模式、Node.js with nodemon），修改会自动生效，体验与本地开发几乎无异。

2.4 依赖管理：如何高效安装

依赖安装是另一个需要优化的点。我们不应该在每次启动容器时都重新 pip install 或 npm install 。最佳实践是：

  1. 在 Dockerfile 中安装依赖 ：将依赖文件（ requirements.txt , package.json ）复制进镜像，然后执行安装。Docker的层缓存机制会保证，只要依赖文件没变，这一层就会被复用，无需重新下载和编译。

    # Dockerfile.dev 片段
FROM python:3.11
WORKDIR /app
# 先复制依赖文件，利用缓存
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
# 然后再复制代码
COPY . .

  2. 使用Docker Compose管理服务依赖 ：如果你的应用依赖数据库、Redis等，用 docker-compose.yml 定义所有服务，一键启停，网络自动互通，比手动启动一堆容器方便太多。

3. 实战搭建：一个Python Flask应用的Docker开发环境

让我们通过一个具体的例子，把上面的理论落地。我们将为一个简单的Flask Web应用搭建开发环境。

3.1 项目结构与文件准备

假设项目结构如下：

my_flask_app/
├── app.py
├── requirements.txt
├── Dockerfile.dev
└── docker-compose.yml
  • app.py 是我们的应用入口。
  • requirements.txt 列出了Python依赖。
  • Dockerfile.dev 是开发专用的Dockerfile。
  • docker-compose.yml 用于编排服务（可能包含数据库）。

3.2 编写开发专用的Dockerfile

创建 Dockerfile.dev ：

# 使用完整的官方Python镜像作为基础，便于安装需要编译的包
FROM python:3.11

# 设置工作目录
WORKDIR /app

# 设置环境变量，确保Python输出直接显示在终端，不缓冲
ENV PYTHONUNBUFFERED=1

# 先复制依赖列表文件，这一步可以充分利用Docker的缓存
# 只要requirements.txt不变，就不会重新执行pip install
COPY requirements.txt .

# 安装Python依赖
# --no-cache-dir 避免缓存，减小镜像体积（虽然开发镜像不苛求，但好习惯）
# -r requirements.txt 从文件安装
RUN pip install --no-cache-dir -r requirements.txt

# 将当前目录所有文件复制到容器的/app目录
# 注意：这里使用 .dockerignore 文件来排除不需要的文件（如虚拟环境目录、__pycache__）非常重要！
COPY . .

# 暴露Flask默认端口
EXPOSE 5000

# 以调试模式启动Flask应用
# --host=0.0.0.0 让服务监听所有网络接口，这样可以从宿主机访问
# --reload 启用代码热重载，修改代码后自动重启
CMD ["flask", "run", "--host=0.0.0.0", "--reload"]

关键点解析 ：

  1. PYTHONUNBUFFERED=1 ：这个环境变量对于在Docker中运行Python应用至关重要。它强制Python标准输出和标准错误流不经过缓冲，直接输出。这样，你在 docker logs 或终端里才能实时看到 print 语句和日志输出，而不是等缓冲区满了才看到。
  2. 复制顺序：先 COPY requirements.txt . 再 RUN pip install ，最后 COPY . . 。这是一个经典优化技巧。因为代码变更频率远高于依赖变更，这样可以利用Docker层缓存，避免在每次代码修改后都重新安装依赖。
  3. --reload ：这是开发模式的核心，提供了热重载功能。
  4. .dockerignore 文件：务必创建。内容至少包含 venv/ , __pycache__/ , .git/ , *.pyc , .env 。这能防止将本地虚拟环境、缓存文件等不必要的或敏感的文件复制进镜像，既能减小镜像体积，也能避免覆盖容器内的配置。

3.3 编写Docker Compose文件

创建 docker-compose.yml ，即使目前只有一个服务，使用Compose也能简化命令，并为未来添加数据库等做准备。

version: '3.8'

services:
  web:
    build:
      context: .  # 构建上下文为当前目录
      dockerfile: Dockerfile.dev  # 指定使用开发Dockerfile
    ports:
      - "5000:5000"  # 将宿主机的5000端口映射到容器的5000端口
    volumes:
      - .:/app  # 绑定挂载，实现代码实时同步
      # 可选：挂载一个命名卷来缓存pip包，加速后续构建（如果requirements.txt不变）
      - pip-cache:/root/.cache/pip
    environment:
      - FLASK_APP=app.py  # 设置Flask应用入口环境变量
      - FLASK_ENV=development  # 设置为开发环境（旧版Flask）
      # 注意：新版Flask推荐使用 FLASK_DEBUG=1
      - FLASK_DEBUG=1
    # 设置容器内的工作目录，与Dockerfile中保持一致
    working_dir: /app
    # 因为我们在Dockerfile的CMD中已经定义了启动命令，这里可以省略command
    # 如果覆盖，可以写：command: flask run --host=0.0.0.0 --reload

# 定义命名卷，用于持久化或缓存
volumes:
  pip-cache:

3.4 启动与开发

现在，一切就绪。在项目根目录下，执行一条命令：

docker-compose up

你会看到Docker开始构建镜像（第一次），然后启动容器。终端会输出Flask的开发服务器日志。此时，在浏览器中访问 http://localhost:5000 ，就能看到你的应用了。

开发流程 ：

  1. 在宿主机上用你喜欢的IDE（VSCode, PyCharm等）打开 my_flask_app 项目。
  2. 修改 app.py 中的代码，保存。
  3. 观察运行 docker-compose up 的终端，Flask的重载器会检测到文件变化，自动重启应用。
  4. 刷新浏览器，更改立即生效。

停止服务 ：在终端按 Ctrl+C 。如果想在后台运行，使用 docker-compose up -d ，查看日志用 docker-compose logs -f web 。

4. 进阶技巧与优化：提升开发体验

基础搭建完成后，我们可以追求更丝滑的开发体验。

4.1 调试：在容器内进行断点调试

代码热重载解决了“改代码看效果”的问题，但复杂的Bug需要断点调试。我们需要让IDE能够连接到容器内运行的Python解释器。

以VSCode为例 ：

  1. 在项目根目录创建 .vscode/launch.json 文件。

  2. 安装VSCode的 Remote - Containers 或 Python 扩展。

  3. 一个简单的配置示例如下（这需要你的应用以可调试模式启动，例如使用 debugpy ）：

    首先，修改 Dockerfile.dev ，安装调试器并改变启动方式：

    RUN pip install debugpy
CMD ["python", "-m", "debugpy", "--listen", "0.0.0.0:5678", "--wait-for-client", "-m", "flask", "run", "--host=0.0.0.0"]

    然后，在 docker-compose.yml 中暴露调试端口：

    ports:
  - "5000:5000"
  - "5678:5678" # 调试端口

    最后，配置VSCode的 launch.json ，附加到该调试端口。

更现代、更集成化的方式是使用 Dev Containers 。你可以在项目下创建 .devcontainer/devcontainer.json 配置文件，VSCode能直接打开并进入一个完全配置好的容器环境进行开发，包括调试、终端、扩展都运行在容器内，体验无缝。

4.2 依赖变更：如何更新 requirements.txt

开发中经常需要添加新包。步骤应该是：

  1. 在宿主机上，如果愿意，可以激活一个虚拟环境（但非必须），然后 pip install some-new-package 。
  2. 更新 requirements.txt ： pip freeze > requirements.txt （注意这会覆盖文件，确保只包含项目依赖）或使用 pipreqs 工具生成。
  3. 重建Docker镜像 ：由于 requirements.txt 内容变了，Docker的缓存会失效，从 RUN pip install... 那一层开始重建。执行 docker-compose up --build 。 --build 参数强制重新构建镜像。

4.3 使用Docker Compose管理多服务开发环境

真实项目很少只有一个Web服务。通常还有数据库、缓存、消息队列等。Docker Compose的强大之处就在这里。

version: '3.8'
services:
  web:
    build: .
    ports: ["5000:5000"]
    volumes: [".:/app"]
    depends_on:
      - db
      - redis
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/mydb
      - REDIS_URL=redis://redis:6379/0
    networks:
      - mynetwork

  db:
    image: postgres:15-alpine
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=mydb
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - mynetwork

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    networks:
      - mynetwork

  # 甚至可以加一个管理工具，如PgAdmin
  pgadmin:
    image: dpage/pgadmin4
    environment:
      - PGADMIN_DEFAULT_EMAIL=admin@example.com
      - PGADMIN_DEFAULT_PASSWORD=admin
    ports:
      - "8080:80"
    depends_on:
      - db
    networks:
      - mynetwork

volumes:
  postgres_data:
  redis_data:

networks:
  mynetwork:
    driver: bridge

现在，只需要 docker-compose up ，一个包含Web应用、PostgreSQL数据库、Redis缓存和数据库管理界面的完整开发环境就启动了。服务间通过服务名（如 db , redis ）直接通信，网络自动隔离，与宿主机环境完全无关。

4.4 性能考量：文件系统挂载的I/O开销

在macOS和Windows上，将宿主机的文件系统挂载到Docker容器（特别是通过Docker Desktop的虚拟化层）可能会有显著的I/O性能损耗，导致代码变更后重载变慢。有几种缓解方案：

  • 使用 delegated 或 cached 一致性模式 （在Compose中）： - ./code:/app:delegated 。这表示容器对挂载目录的视图是“委托”的，读写性能更好，但一致性稍弱（对开发环境通常可接受）。
  • 使用Docker的 buildkit 缓存 ：确保 DOCKER_BUILDKIT=1 环境变量已设置，它能提供更智能的构建缓存。
  • 对于Node.js项目 ：可以将 node_modules 作为匿名卷挂载，避免宿主机与容器间的同步开销： - /app/node_modules 。

5. 常见问题与故障排查

即使按照最佳实践操作，也难免会遇到问题。这里记录一些高频问题及其解决思路。

5.1 容器启动后立即退出

这是最常见的问题之一。通常是因为容器内没有 前台进程 在运行。Docker容器需要至少一个前台进程保持运行，如果进程结束，容器就会退出。

  • 检查点 ：
    1. Dockerfile 中的 CMD 或 ENTRYPOINT 是否正确？它是否启动了一个长期运行的服务（如 flask run , npm start , python app.py ）？
    2. 如果命令是启动一个Shell脚本，确保脚本最后是执行一个前台命令，或者用 exec 来执行。
    3. 使用 docker-compose logs [service-name] 查看容器退出前的日志，通常会有错误信息。
  • 临时调试技巧 ：为了排查，可以修改 docker-compose.yml 中该服务的 command 为 tail -f /dev/null 或 sleep infinity ，这是一个永远不结束的前台命令，让你有机会 docker-compose exec [service] sh 进入容器内部进行检查。

5.2 端口被占用或无法访问

  • 症状 ： docker-compose up 时报错 Bind for 0.0.0.0:5000 failed: port is already allocated 。
  • 解决 ：
    1. 确认宿主机5000端口是否被其他程序占用： lsof -i :5000 (macOS/Linux) 或 netstat -ano | findstr :5000 (Windows)。
    2. 修改 docker-compose.yml 中的端口映射，例如改为 "5001:5000" 。
  • 症状 ：端口映射正确，但浏览器访问 localhost:5000 连接失败。
  • 解决 ：
    1. 检查容器内应用是否真的在监听 0.0.0.0 而不是 127.0.0.1 。很多框架默认只监听本地回环，在容器内需要显式绑定到 0.0.0.0 。
    2. 检查防火墙设置，是否阻止了Docker虚拟网卡的通信。
    3. 进入容器内部 ( docker-compose exec web sh )，尝试用 curl localhost:5000 看服务是否正常。如果容器内正常，但宿主机无法访问，问题通常出在网络或端口映射上。

5.3 文件权限问题

当容器内进程（如Web服务器）尝试写入挂载的宿主机目录时，可能会因用户ID（UID）不匹配而出现权限错误。

  • 典型场景 ：Flask应用想在挂载的 ./uploads 目录下保存用户上传的文件，报错 Permission denied 。
  • 解决方案 ：
    1. （推荐）在容器内使用与宿主机相同的UID/GID ：在 Dockerfile 中创建运行时用户时，使用固定的、已知的UID（如1000，通常是第一个桌面用户的UID）。例如： 
      RUN groupadd -r appuser -g 1000 && useradd -r -u 1000 -g appuser appuser
USER appuser
    2. 调整宿主机目录权限 ：将宿主机目录的权限改为更宽松（如 chmod 777 ），但这有安全风险，不推荐在生产相关目录使用。
    3. 使用Docker的命名卷 ：对于需要持久化且由容器内进程写入的数据，使用Docker卷（volume）而非绑定挂载（bind mount）。卷由Docker管理，权限问题较少。

5.4 依赖安装慢或失败

  • 使用国内镜像源 ：在 Dockerfile 中， pip 和 apt 都可以换源。 
    RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple
    对于 apt ，可以在 RUN 命令前先复制一个 sources.list 文件，或使用sed命令替换。
  • 构建缓存失效 ：确保 .dockerignore 文件正确，避免不必要的文件变更导致缓存失效。合理安排 Dockerfile 中 COPY 和 RUN 命令的顺序，将变化频率低的层放在前面。
  • 网络问题 ：在某些网络环境下，需要为Docker Daemon配置HTTP代理。

5.5 Docker Desktop启动失败：虚拟化支持问题

这是一个在Windows和macOS上常见的环境问题，虽然不直接属于“在Docker中开发”的范畴，但却是前提。错误信息常包含“virtualisation support wasn’t detected”或“Hardware assisted virtualization and data execution protection must be enabled”。

  • Windows (Hyper-V/WSL2) :
    1. 进入BIOS/UEFI设置，确保 Intel VT-x 或 AMD-V 虚拟化技术已启用。
    2. 确保 Windows功能 中 Hyper-V 和 Windows Subsystem for Linux 已勾选启用。
    3. Docker Desktop默认使用WSL2后端，确保已安装WSL2内核更新包，并设置默认WSL发行版为WSL2： wsl --set-default-version 2 。
  • macOS :
    1. 对于Intel芯片Mac，确保在 系统偏好设置 -> 安全性与隐私 -> 通用 中允许来自Oracle的“系统软件”。
    2. 对于Apple Silicon (M1/M2等) Mac，Docker Desktop原生支持，但需要确认使用的是支持ARM64的镜像（很多官方镜像已提供多架构支持）。

6. 从开发到生产：构建优化与CI/CD集成

开发环境搭好了，最终我们的应用要部署上线。这时就需要一个为生产环境优化的 Dockerfile 。

6.1 生产级Dockerfile示例

# 第一阶段：构建阶段
FROM python:3.11-slim AS builder

WORKDIR /app

# 安装构建依赖（编译工具等）
RUN apt-get update && apt-get install -y \
    gcc \
    g++ \
    --no-install-recommends && \
    rm -rf /var/lib/apt/lists/*

# 复制依赖文件
COPY requirements.txt .
# 在构建阶段安装依赖，可以安装到特定目录
RUN pip install --user --no-cache-dir -r requirements.txt

# 第二阶段：运行阶段
FROM python:3.11-slim

WORKDIR /app

# 从构建阶段复制已安装的Python包
COPY --from=builder /root/.local /root/.local
# 复制应用代码
COPY . .

# 确保运行时可以找到从 --user 安装的包
ENV PATH=/root/.local/bin:$PATH
# 创建一个非root用户运行应用，增强安全性
RUN useradd -m -u 1000 appuser && chown -R appuser:appuser /app
USER appuser

# 暴露端口
EXPOSE 5000

# 定义健康检查
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
    CMD python -c "import requests; requests.get('http://localhost:5000/health', timeout=2)" || exit 1

# 使用Gunicorn等WSGI服务器运行应用，而不是Flask开发服务器
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "4", "app:app"]

这个生产Dockerfile的特点：

  1. 多阶段构建 ：第一阶段（ builder ）包含编译工具，用于安装依赖。第二阶段基于更干净的 slim 镜像，只从第一阶段复制安装好的包，最终镜像体积小、漏洞少。
  2. 使用非root用户 ：避免容器以root权限运行，遵循最小权限原则。
  3. 健康检查 ：让Docker或编排器（如Kubernetes）能感知应用状态。
  4. 使用生产级服务器 ：用 Gunicorn 替代Flask自带的开发服务器，后者性能差且不安全。

6.2 与CI/CD流水线集成

在团队协作中，Docker镜像的构建和推送应该自动化。以GitHub Actions为例，一个简单的流水线可能包含以下步骤：

# .github/workflows/build-and-push.yml
name: Build and Push Docker Image

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Log in to Docker Hub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v4
        with:
          context: .
          file: ./Dockerfile # 指定生产Dockerfile
          push: true
          tags: |
            yourusername/your-app:latest
            yourusername/your-app:${{ github.sha }}

这条流水线会在代码推送到 main 分支时自动触发，构建生产镜像并推送到Docker Hub。后续可以衔接部署步骤，实现持续部署。

7. 总结与个人体会

在Docker中进行开发，从最初的“多此一举”到如今的“不可或缺”，我个人的体会是，它带来的最大价值是 确定性 和 可复现性 。它把开发环境从一种“个人艺术”变成了“团队工程”。新人上手的时间从天缩短到分钟，线上Bug的复现从猜谜变成可追溯的实验。

当然，它也不是银弹。初期需要投入时间学习Docker和Docker Compose的语法，编写和维护 Dockerfile 、 docker-compose.yml 也需要成本。对于极其简单的个人脚本项目，可能有点杀鸡用牛刀。但对于任何稍具规模、需要协作、或依赖复杂外部服务的项目，这笔投资绝对物超所值。

最后分享一个小技巧：如果你发现某个依赖在容器内安装特别慢，或者需要复杂的系统库，不妨先搜索一下有没有对应的 官方Docker镜像 。比如， psycopg2 的安装需要 libpq-dev ，你可以在 Dockerfile 里先 apt-get install 它。很多常见软件的安装问题，在Docker Hub该镜像的文档里都有现成答案。善用现有镜像和社区经验，能让你在容器化的道路上走得更顺。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

【Flink SQL 学习笔记 二】实时聚合：用窗口和 Watermark 把订单按时段统计

avatar 亚马逊云科技技术品牌专区

2026 大模型量化：怎么把 70B 大模型塞进 24G 显存？（MonkeyCode 云端实战）

2026年开源大模型参数动辄几百亿，模型文件动辄上百GB，能不能跑起来比的不是代码写得多漂亮，而是谁更会"压缩"。本文讲透大模型量化：量化到底在压什么？核心公式、PTQ与QAT两条路线、INT8/INT4位宽与精度权衡、混合精度的聪明做法，以及量化如何让端侧离线环境都能跑大模型。用MonkeyCode云端沙箱跑真实量化流程，让AI自己写代码加载模型、做量化、实测显存与速度对比，内置多款主流大模型一

avatar 亚马逊云科技技术品牌专区

AutoDL部署大模型dots.ocr

大模型部署

avatar 亚马逊云科技技术品牌专区