数据科学家必学的Docker实战：从环境一致性到ML模型交付

1. 为什么数据科学家必须亲手敲下第一个 docker run hello-world

你有没有经历过这样的深夜：模型在本地 Jupyter Notebook 里跑得飞起，准确率 92.3%，连交叉验证都做了三轮；可一到测试环境， ImportError: No module named 'xgboost' 直接报错；换到预发环境，又变成 OSError: libgomp.so.1: cannot open shared object file ；最后上线那天，运维同事盯着屏幕说：“你这个 Python 版本和我们基础镜像不兼容，得改。”——那一刻，你不是数据科学家，你是“环境修复工程师”。

这不是个例。我带过的 7 个数据科学项目组里，平均每个项目在部署阶段因环境不一致多花 11.6 小时。有位同事甚至用 Excel 表格手动记录了他本地、测试机、生产服务器上所有 Python 包的版本号，就为了找出那个导致 pandas 读取 Parquet 文件失败的 pyarrow 小版本差异。这太荒谬了。我们是来解决业务问题的，不是来当系统管理员的。

Docker 对数据科学家的意义，从来不是“又一个要学的新工具”，而是 把“我的代码在哪都能跑”从一句口号，变成一条可验证、可交付、可审计的技术承诺 。它不改变你写模型的方式，但彻底改变了你交付模型的方式。你不再需要向运维解释“我本地装的是 conda-forge 的 scipy 1.10.1，不是默认 channel 的 1.9.3”，你只需要说：“请拉取 my-ml-pipeline:v2.4.1 这个镜像， docker run 就行。”——这句话背后，是你对整个运行时环境的绝对掌控。它让数据科学家第一次真正拥有了“端到端交付权”，而不仅仅是“模型开发权”。这才是容器化在数据科学领域最根本的价值： 把不可控的“环境变量”，变成可控的“代码资产” 。

2. Docker 在数据科学工作流中的真实定位与设计逻辑

2.1 它不是替代品，而是“环境契约”的签署方

很多数据科学家初学 Docker 时有个巨大误区：以为它是个更高级的虚拟环境（virtualenv）或包管理器（conda）。这是危险的。 virtualenv 只管 Python 包， conda 能管点 C 库，但它们都依赖于宿主机的操作系统、内核版本、GPU 驱动、CUDA 工具链。而 Docker 的核心契约是： “只要宿主机有 Docker Engine，我的应用就该以完全相同的行为运行。” 这个契约覆盖了从内核模块（如 nvidia-container-toolkit ）、GPU 驱动、CUDA/cuDNN 版本，到 Python 解释器、所有 pip/conda 包、甚至字体渲染库（比如 matplotlib 画图时缺 libfreetype ）的全栈一致性。

我见过最典型的反面案例，是一个用 TensorFlow 2.8 + CUDA 11.2 训练的推荐模型。团队在 Ubuntu 20.04 上开发，测试环境是 CentOS 7，生产环境是 Amazon Linux 2。三个系统内核版本差了 3 年， glibc 版本不一致， nvidia-smi 输出的驱动版本也不同。 conda activate 后 python -c "import tensorflow" 能过，但一调用 tf.data 的并行读取，就 core dump。最终发现是 libcuda.so 的符号链接在不同系统上指向了不同路径。这种问题， conda 无能为力，但 Docker 可以——因为你在 Dockerfile 里明确指定了基础镜像 nvidia/cuda:11.2.2-cudnn8-runtime-ubuntu20.04 ，所有依赖都从这个确定的起点构建，彻底规避了宿主机差异。

2.2 容器化不是终点，而是 CI/CD 流水线的“标准化输入”

在成熟的数据平台中，Docker 镜像早已不是部署时才生成的产物，而是整个机器学习生命周期的“事实标准”。它的上游是训练流水线（Training Pipeline），下游是模型服务（Model Serving）和监控（Monitoring）。一个典型的闭环是：

1. 训练触发 ：数据更新或超参调整后，CI 系统自动拉取最新代码，启动训练任务；
2. 镜像构建 ：训练脚本执行完毕，自动触发 docker build ，将训练好的模型文件（ .pkl , .h5 , saved_model ）、推理代码、 requirements.txt 和 Dockerfile 打包成镜像；
3. 自动化测试 ：新镜像被推送到私有 Registry 后，自动启动一个容器，运行单元测试（如 pytest test_inference.py ）和集成测试（如用 mock 数据请求 /predict 接口）；
4. 灰度发布 ：测试通过后，新镜像被部署到灰度集群，流量 5%；监控指标（延迟、错误率、特征漂移）达标后，全量发布。

在这个流程里，Docker 镜像就是那个“不可变的、可追溯的、可测试的”交付物。它让“模型上线”这件事，从一次充满不确定性的手工操作，变成了一个可重复、可回滚、可审计的原子步骤。你不需要记住“上周三发布的模型用的是哪个 Git commit”，你只需要看镜像标签 my-model:20231025-1432-prod ，就能精确还原出当时的所有代码、依赖和配置。

2.3 为什么选择 Docker 而非其他方案？技术选型背后的硬逻辑

2013 年 Docker 出现时，LXC（Linux Containers）已经存在多年。为什么是 Docker 火了？答案藏在它的设计哲学里： “开发者体验优先”（Developer Experience First） 。LXC 更像一个底层内核接口的封装，而 Docker 则是一整套围绕“如何让开发者轻松创建、分享、运行容器”的工程实践。

具体到数据科学场景，这个优势体现为三点：

• 分层镜像（Layered Filesystem） ：Docker 镜像由只读层堆叠而成。 FROM nvidia/cuda:11.2... 是第一层， COPY requirements.txt . 是第二层， RUN pip install -r requirements.txt 是第三层……每一层都是一个独立的缓存单元。这意味着，当你只修改了模型代码（ COPY model.py . ），Docker 构建时会复用之前所有层的缓存， pip install 步骤直接跳过，构建时间从 8 分钟缩短到 22 秒。这对需要频繁迭代的模型开发至关重要。
• 声明式配置（Declarative Configuration） ： Dockerfile 是纯文本，可以像代码一样进行版本控制、Code Review、自动化扫描（如 trivy 检查漏洞）。你可以在 PR 中清晰地看到：“这次升级了 scikit-learn 从 1.1.2 到 1.2.0，同时修复了 pandas 的 CVE-2023-27501”。这在传统“运维给个服务器账号，你自己配环境”的模式下是无法想象的。
• 生态整合（Ecosystem Integration） ：Docker Hub 是公开的“容器应用商店”， nvidia/cuda 、 continuumio/anaconda3 、 tensorflow/tensorflow 这些官方镜像，为你省去了 90% 的基础环境搭建工作。更重要的是，它与 Kubernetes、GitHub Actions、GitLab CI 等现代 DevOps 工具无缝集成。你不需要自己写脚本去上传镜像、配置负载均衡，这些都有成熟的 Action 或 Operator 帮你完成。

提示：不要试图在 Dockerfile 里 RUN apt-get update && apt-get install -y ... 安装大量系统级软件。这会破坏镜像的可移植性，并增加安全风险。正确的做法是：优先寻找已有的、维护良好的基础镜像（如 nvidia/cuda 、 python:3.9-slim ），再在其上叠加你的 Python 依赖。如果必须安装系统包，务必使用 --no-install-recommends 参数精简体积，并在 apt-get 后立即 rm -rf /var/lib/apt/lists/* 清理缓存。

3. 核心细节解析：从零构建一个可复现的 ML 推理服务

3.1 Dockerfile 的黄金结构与避坑指南

一个健壮的 Dockerfile 不是功能堆砌，而是对“最小化、安全性、可复现性”三原则的践行。下面是我为一个基于 Flask 的分类模型服务编写的 Dockerfile ，并逐行解析其设计意图：

# 第1行：选择最精简、最安全的基础镜像
# 使用 python:3.9-slim-bullseye 而非 python:3.9 或 python:3.9-slim
# bullseye 是 Debian 11，比 stretch/buster 更新，安全补丁更全；slim 版本不含 man pages、dev headers 等非必要文件
FROM python:3.9-slim-bullseye

# 第2-3行：设置非 root 用户，强制安全基线
# 默认的 root 用户是安全隐患。创建一个 UID 1001 的用户，并切换过去
RUN adduser --disabled-password --gecos "" --shell /bin/bash --home /home/appuser --uid 1001 appuser
USER appuser
WORKDIR /home/appuser

# 第4-5行：复制依赖清单，提前构建，利用 Docker 缓存
# 先复制 requirements.txt，再 pip install，这样只有当依赖变更时才重新安装
# --no-cache-dir 避免在镜像中留下 pip 缓存，减小体积
# --user 安装到用户目录，避免权限问题（因为当前是 appuser）
COPY requirements.txt .
RUN pip install --no-cache-dir --user -r requirements.txt

# 第6-7行：复制应用代码，放在依赖之后
# 这样，修改代码不会触发 pip install，极大加速开发迭代
COPY . .

# 第8行：设置 PATH，让 pip --user 安装的可执行文件能被找到
ENV PATH=/home/appuser/.local/bin:$PATH

# 第9行：暴露端口，这是文档化的契约
EXPOSE 5000

# 第10行：定义健康检查，供编排系统（如 Kubernetes）使用
# 容器启动后，每30秒执行一次 curl -f http://localhost:5000/health || exit 1
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:5000/health || exit 1

# 第11行：定义启动命令，使用 gunicorn 替代默认的 flask run
# gunicorn 是生产级 WSGI 服务器，支持多 worker、优雅重启、日志管理
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "--workers", "2", "--access-logfile", "-", "--error-logfile", "-", "app:app"]

关键避坑点实录：

• 陷阱： pip install 放在 COPY . . 之后
  后果：每次修改任何一行代码（哪怕只是改了个注释），Docker 都会重新执行 pip install ，构建时间爆炸。
  解决：严格遵守“先 COPY 依赖，再 INSTALL，最后 COPY 代码”的三层结构。

• 陷阱：使用 pip install 安装 numpy 、 scipy 等重型包
  后果：在 slim 镜像中，缺少 build-essential 、 gfortran 等编译工具， pip install 会尝试从源码编译，耗时极长且极易失败。
  解决：在 requirements.txt 中指定预编译的 wheel 包，或改用 conda （需基础镜像支持），或直接选用 continuumio/anaconda3 这类已预装好科学计算栈的镜像。

• 陷阱： CMD 中使用 flask run --host=0.0.0.0:5000
  后果： flask run 是开发服务器，单线程、无生产级特性（如连接池、超时控制），在高并发下会崩溃。
  解决：必须使用 gunicorn 、 uWSGI 或 uvicorn （对 ASGI）等生产级服务器，并配置合理的 --workers 数量（通常为 CPU 核数 * 2 + 1）。

3.2 requirements.txt 的精准锁定： pip freeze 的致命缺陷

很多团队直接 pip freeze > requirements.txt ，这是灾难的开始。 pip freeze 会输出所有已安装包，包括 setuptools 、 wheel 、 pip 自身，以及那些作为依赖被间接安装的包（如 pandas 依赖的 pytz 、 dateutil ）。这会导致两个严重问题：

1. 版本漂移（Version Drift） ： pandas==1.5.3 依赖 pytz==2022.7 ，但 pip freeze 会把 pytz==2022.7 也写死。下次 pandas 升级到 1.5.4 ，可能要求 pytz>=2023.1 ，但你的 requirements.txt 强制锁死了旧版，导致冲突。
2. 安全盲区（Security Blind Spot） ： pip freeze 不会告诉你某个包的子依赖是否有高危漏洞（CVE）。例如， requests==2.28.1 本身安全，但它依赖的 urllib3<1.26.12 可能有 RCE 漏洞。

正确做法：使用 pip-tools 进行依赖解析。
第一步，创建 requirements.in ，只写你直接依赖的包：

# requirements.in
scikit-learn>=1.1.0,<1.2.0
pandas>=1.5.0,<1.6.0
flask>=2.2.0,<2.3.0
gunicorn>=21.2.0,<22.0.0

第二步，用 pip-compile 生成精准、可复现的 requirements.txt ：

pip install pip-tools
pip-compile requirements.in --output-file requirements.txt

生成的 requirements.txt 会长这样：

# This file is autogenerated by pip-compile with Python 3.9
# by the following command:
#
#    pip-compile requirements.in
#
certifi==2023.7.22
charset-normalizer==3.2.0
click==8.1.6
...
scikit-learn==1.1.3
# via -r requirements.in

它不仅锁定了所有直接和间接依赖的精确版本，还在注释中说明了每个包的来源（ via -r requirements.in ），并记录了生成命令和 Python 版本，确保了绝对的可复现性。

注意： pip-tools 生成的 requirements.txt 中， # via 注释是关键。它让你一眼看出 scikit-learn==1.1.3 是因为你写了 scikit-learn>=1.1.0,<1.2.0 ，而不是某个隐藏的依赖。这在排查兼容性问题时，价值千金。

3.3 GPU 加速模型的容器化：绕不开的 CUDA 与驱动鸿沟

如果你的模型需要 GPU 推理（如 PyTorch 、 TensorFlow ），容器化会变得复杂，因为涉及硬件驱动与用户空间库的协同。核心矛盾在于： NVIDIA 驱动（ nvidia-driver ）是内核模块，必须安装在宿主机上；而 CUDA 工具包（ cuda-toolkit ）是用户空间库，可以打包进容器。

Docker 本身不处理 GPU，它依赖 nvidia-container-toolkit （原 nvidia-docker2 ）。这个工具的作用，是在容器启动时，将宿主机上的 NVIDIA 驱动文件（ /dev/nvidiactl , /dev/nvidia-uvm , /usr/lib/x86_64-linux-gnu/libcuda.so.* ）以只读方式挂载进容器。因此， 宿主机的 NVIDIA 驱动版本，必须兼容容器内 CUDA 应用所需的 CUDA 运行时版本。 这是一个经典的“版本矩阵”问题。

实操步骤：

1. 确认宿主机驱动 ：在服务器上运行 nvidia-smi ，看右上角显示的驱动版本（如 Driver Version: 510.47.03 ）。
2. 选择匹配的基础镜像 ：根据驱动版本，去 NVIDIA Container Toolkit 官方文档 查找支持的 CUDA 版本，然后选择对应的 nvidia/cuda 镜像。例如，驱动 510.47.03 支持最高 CUDA 11.6 ，则 Dockerfile 第一行应为：

FROM nvidia/cuda:11.6.2-cudnn8-runtime-ubuntu20.04

3. 在容器内验证 GPU 可用性 ：在 Dockerfile 末尾添加测试命令：

# 在构建时验证 CUDA 是否可用
RUN python -c "import torch; print(f'PyTorch {torch.__version__}'); print(f'CUDA available: {torch.cuda.is_available()}'); print(f'CUDA version: {torch.version.cuda}')"

如果构建失败，说明基础镜像与驱动不匹配，必须更换。

4. 运行时启用 GPU ：启动容器时，必须加上 --gpus all 参数：

docker run --gpus all -p 5000:5000 my-gpu-model:latest

血泪教训： 我曾在一个项目中，宿主机驱动是 450.80.02 ，却错误地选用了 nvidia/cuda:11.4.2-cudnn8-runtime-ubuntu20.04 。 nvidia-smi 在容器内能正常显示，但 torch.cuda.is_available() 返回 False 。花了整整一天排查，最终发现 CUDA 11.4 需要驱动 470.x ，而 450.x 只支持到 CUDA 11.0 。这个教训让我养成了一个习惯：在项目 README 里，用表格明确写出“本模型镜像要求的最低宿主机 NVIDIA 驱动版本”，并把它作为上线前的必检项。

4. 实操过程：手把手 Dockerize 一个 Scikit-learn 分类模型

4.1 项目结构与最小可行代码

我们以一个极简但真实的场景为例：一个用 scikit-learn 训练的鸢尾花（Iris）分类模型，提供 REST API 进行预测。项目结构如下：

iris-classifier/
├── Dockerfile
├── requirements.in
├── app.py
├── model.pkl
└── README.md

app.py 是核心 Flask 应用：

from flask import Flask, request, jsonify
import pickle
import numpy as np

app = Flask(__name__)

# 加载预训练模型（假设 model.pkl 已存在）
with open('model.pkl', 'rb') as f:
    model = pickle.load(f)

@app.route('/predict', methods=['POST'])
def predict():
    try:
        # 解析 JSON 请求体
        data = request.get_json()
        features = np.array(data['features']).reshape(1, -1)
        
        # 模型预测
        prediction = model.predict(features)[0]
        probability = model.predict_proba(features)[0].max()
        
        return jsonify({
            'prediction': int(prediction),
            'probability': float(probability),
            'class_name': ['setosa', 'versicolor', 'virginica'][int(prediction)]
        })
    except Exception as e:
        return jsonify({'error': str(e)}), 400

@app.route('/health', methods=['GET'])
def health():
    return jsonify({'status': 'ok'})

if __name__ == '__main__':
    app.run(host='0.0.0.0:5000', debug=False)

requirements.in 内容：

flask>=2.2.0,<2.3.0
scikit-learn>=1.1.0,<1.2.0
gunicorn>=21.2.0,<22.0.0

4.2 构建、测试、推送全流程详解

步骤 1：生成精准的 requirements.txt

# 在项目根目录执行
pip-compile requirements.in --output-file requirements.txt

这会生成一个包含 flask==2.2.5 , scikit-learn==1.1.3 , gunicorn==21.2.0 等精确版本的 requirements.txt 。

步骤 2：构建镜像

# 构建并打标签，-t 指定镜像名和标签
docker build -t iris-classifier:1.0.0 .

# 查看构建过程，确认每一层是否命中缓存
# 你会看到类似这样的输出，证明 pip install 层被缓存了：
# => CACHED [4/7] RUN pip install --no-cache-dir --user -r requirements.txt

步骤 3：本地测试镜像

# 启动容器，映射端口 5000
docker run -p 5000:5000 iris-classifier:1.0.0

# 在另一个终端，发送测试请求
curl -X POST http://localhost:5000/predict \
  -H "Content-Type: application/json" \
  -d '{"features": [5.1, 3.5, 1.4, 0.2]}'

# 预期返回：
# {"class_name":"setosa","prediction":0,"probability":0.9999999999999999}

步骤 4：使用 docker-compose 进行多容器协作（可选但推荐） 对于更复杂的项目（如前端+后端+数据库）， docker-compose.yml 是必备技能。一个简单的 docker-compose.yml 示例：

version: '3.8'
services:
  web:
    image: iris-classifier:1.0.0
    ports:
      - "5000:5000"
    # 添加健康检查，供 compose 监控
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    # 设置资源限制，防止一个容器吃光所有内存
    mem_limit: 512m
    cpus: 1.0

启动命令：

docker-compose up -d
# 查看服务状态
docker-compose ps
# 查看日志
docker-compose logs -f web

步骤 5：推送至私有 Registry

# 假设你的私有 Registry 地址是 registry.mycompany.com
# 先登录
docker login registry.mycompany.com

# 给镜像打上 Registry 标签
docker tag iris-classifier:1.0.0 registry.mycompany.com/ml/iris-classifier:1.0.0

# 推送
docker push registry.mycompany.com/ml/iris-classifier:1.0.0

4.3 生产环境部署的关键配置与参数

仅仅 docker run 是不够的。在生产环境中，你需要关注以下参数：

• 资源限制（Resource Limits） ：防止一个失控的容器耗尽服务器资源。

  docker run \
    --memory=512m \          # 最大内存 512MB
    --memory-swap=512m \     # 总内存+swap 512MB（即禁用 swap）
    --cpus=1.0 \             # 最多使用 1 个 CPU 核心
    --restart=always \       # 容器退出时自动重启
    -p 5000:5000 \
    registry.mycompany.com/ml/iris-classifier:1.0.0
  

• 日志驱动（Logging Driver） ：避免日志填满磁盘。

  docker run \
    --log-driver=json-file \
    --log-opt max-size=10m \
    --log-opt max-file=3 \
    ...
  

• 网络与安全（Network & Security） ：

  docker run \
    --network=ml-network \           # 使用自定义网络，而非默认 bridge
    --read-only \                    # 文件系统只读，提升安全性
    --tmpfs /tmp:rw,size=64m \       # 为 /tmp 创建内存文件系统
    --cap-drop=ALL \                 # 删除所有 Linux Capabilities
    --security-opt=no-new-privileges \ # 禁止容器内进程获取新权限
    ...
  

注意： --read-only 选项意味着你的应用不能向 /app 、 /home/appuser 等目录写入任何文件。如果模型需要保存中间状态（如 joblib 缓存），你必须在 Dockerfile 中显式创建一个可写的 tmpfs 或挂载一个 volume 。这是一个常见的“只读失败”陷阱。

5. 常见问题与排查技巧实录

5.1 “ImportError: No module named 'xxx'” —— 依赖未安装的终极排查法

这个问题看似简单，但根源往往很隐蔽。以下是系统化的排查流程：

1. 进入容器内部，确认 Python 环境 ：

   # 启动一个交互式容器
   docker run -it --rm iris-classifier:1.0.0 /bin/bash
   # 在容器内执行
   which python
   python -m site
   pip list | grep -i xxx
   

   如果 pip list 里没有 xxx ，说明 pip install 步骤没执行成功，或者 requirements.txt 里漏写了。

2. 检查 pip install 的输出日志 ： 回看 docker build 的完整输出，搜索 ERROR 或 WARNING 。常见原因是：

   • Could not find a version that satisfies the requirement xxx ： requirements.txt 中的包名拼写错误，或版本范围过于苛刻。
   • Failed building wheel for xxx ：该包需要编译，但 slim 镜像缺少 build-essential 。解决方案是 RUN apt-get update && apt-get install -y build-essential && rm -rf /var/lib/apt/lists/* ，或换用 python:3.9 非 slim 镜像。

3. 检查 PYTHONPATH 和 sys.path ： 在容器内运行：

   python -c "import sys; print('\n'.join(sys.path))"
   

   确认 pip --user 安装的路径（通常是 /home/appuser/.local/lib/python3.9/site-packages ）是否在 sys.path 中。如果不在，说明 ENV PATH=... 没生效，或者 --user 安装失败。

5.2 “Connection refused” 或 “502 Bad Gateway” —— 网络与端口问题

这通常发生在容器启动后，外部无法访问服务。原因及解法：

5.3 “Permission denied” —— 权限与用户问题

这是 non-root 用户模式下的高频问题。典型场景：

• 场景 A：容器启动时报 Permission denied
  原因： CMD 中的可执行文件（如 gunicorn ）没有执行权限，或 app.py 没有读取权限。
  解法：在 Dockerfile 中添加 RUN chmod +x /home/appuser/.local/bin/gunicorn 和 RUN chmod +r app.py 。

• 场景 B：应用运行时报 Permission denied: '/home/appuser/model.pkl'
  原因： model.pkl 文件在宿主机上是 root 所有， appuser 用户无权读取。
  解法：在 Dockerfile 中， COPY 后立即 RUN chown appuser:appuser model.pkl ，或在宿主机上 chmod 644 model.pkl 。

5.4 Docker 镜像体积过大 —— 精简优化实战

一个 scikit-learn 模型服务镜像，理想大小应在 300MB 以内。如果达到 1GB+，说明有严重冗余。优化手段：

1. 多阶段构建（Multi-stage Build） ：将构建环境和运行环境分离。

   # 构建阶段：安装编译工具和构建依赖
   FROM python:3.9-slim-bullseye as builder
   RUN apt-get update && apt-get install -y build-essential && rm -rf /var/lib/apt/lists/*
   COPY requirements.txt .
   RUN pip wheel --no-cache-dir --no-deps --wheel-dir /wheels -r requirements.txt
   
   # 运行阶段：仅复制 wheel 包，不安装编译工具
   FROM python:3.9-slim-bullseye
   COPY --from=builder /wheels /wheels
   RUN pip install --no-cache-dir --no-deps --upgrade /wheels/*.whl
   COPY --chown=appuser:appuser . .
   USER appuser
   ...
   

2. 使用 .dockerignore ：防止不必要的文件（如 __pycache__ , .git , data/ ）被复制进镜像。

   # .dockerignore
   __pycache__
   *.pyc
   .git
   .gitignore
   README.md
   data/
   notebooks/
   

3. 清理构建缓存 ：在 RUN 命令中，将 apt-get 和 pip 的清理合并。

   RUN apt-get update && apt-get install -y --no-install-recommends build-essential && \
       pip install --no-cache-dir -r requirements.txt && \
       apt-get clean && rm -rf /var/lib/apt/lists/*
   

5.5 常见问题速查表

我在实际项目中踩过的最大一个坑，是 model.pkl 文件在 Windows 上生成，然后在 Linux 容器中加载。由于 Windows 和 Linux 的行尾