生产环境 Python Docker 镜像选择 Slim 版本
结论
建议使用官方的 python slim 镜像作为基础镜像，Slim 才是主流生产环境的最佳实践。不建议使用 Alpine 作为 Python 的基础镜像。
python:3.12-slim
Python 3.12 镜像精简版 FROM python:3.12-slim
python 3.12 slim 镜像在极简主义和功能之间提供了良好的平衡，使其成为可扩展技术工具的理想基础。
python 3.12 slim 镜像是一个官方 Python 镜像，构建于最小的 Debian 基础之上，去除了不必要的软件包，以保持镜像尺寸较小——通常约为 30-40 MB，而完整的 Python 镜像则为 100+ MB。
python:3.12-slim 是一个在体积与功能之间取得良好平衡的官方镜像，适合大多数中小型 Python 项目的容器化部署。
主要特点：
- 体积小：相比标准 python:3.12（约 900MB），slim 版本更轻量，便于快速拉取和部署。
- 兼容性良好：基于 glibc，支持大多数 Python 包，尤其是需要编译 C 扩展的库（如 numpy、pandas）。
- 安全性更高：减少不必要的组件，降低潜在攻击面。
- 适用场景：适合 Web 项目、API 服务、科学计算等场景。
Alpine 版本
大多数 Linux 发行版使用 GNU 版本（glibc）的标准 C 库，几乎每个 C 程序都需要这个库，包括 Python。但是 Alpine Linux 使用 musl，Alpine 禁用了 Linux wheel 支持。
理由如下：
- 缺少大量依赖
- CPython 语言运行时的相关依赖
- openssl 相关依赖
- libffi 相关依赖
- gcc 相关依赖
- 数据库驱动相关依赖
- pip 相关依赖
- 构建可能更耗时
- Alpine Linux 使用 musl，一些二进制 wheel 是针对 glibc 编译的，但是 Alpine 禁用了 Linux wheel 支持。现在大多数 Python 包都包括 PyPI 上的二进制 wheel，大大加快了安装时间。但是如果你使用 Alpine Linux，你可能需要编译你使用的每个 Python 包中的所有 C 代码。
glibc 和 musl python 兼容性问题
- Wheel 是预编译二进制包，是 Python 的预编译二进制包格式（.whl 文件）。
- glibc 和 musl 是 Linux 系统的 C 标准库，负责系统调用、内存管理等底层功能。关键问题：glibc 和 musl 的二进制接口（ABI）不同，为 glibc 编译的程序无法在 musl 上运行。
manylinux 是 Python 官方制定的 Linux wheel 标准，确保同一个二进制包能在多个 Linux 发行版上通用运行。
问题所在：
- 99% 的 wheel 是 manylinux（为 glibc 编译）
- Alpine 只支持 musllinux wheel（很少有包提供）
- Alpine 兼容性差，尤其是涉及 C 编译的库，如 numpy、uvloop、psycopg2
- slim 是推荐默认生产镜像：体积和功能的良好平衡
- 不要在生产中用 full 版除非你真的需要所有工具
