这个问题我之前在容器化部署时也踩过坑，核心差异其实来自Alpine的底层库特性以及Python包的预编译支持情况，具体原因和解决方案如下：

一、核心原因：musl libc vs glibc + 缺少预编译Wheel包 #

Alpine Linux默认使用musl libc作为系统C库，而Debian/CentOS等主流发行版用的是glibc。这两者的关键区别在于：

• PyPI上绝大多数科学计算包（包括Pandas、Numpy）针对glibc提供了预编译的wheel包，这类包可以直接下载解压安装，几乎不需要编译时间。
• 针对musl libc的预编译wheel包非常少（甚至很多包完全没有），所以在Alpine上安装时，pip只能从源码编译整个包及其依赖的C扩展模块。编译Numpy/Pandas的C代码本身就非常耗时，这就是你看到setup.py执行时间是Debian 70倍的根本原因。

除此之外，musl和glibc的API细节差异，还会导致编译过程中需要额外的兼容性处理，进一步拉长了编译时间。

二、基于Alpine加速安装的方法 #

如果必须坚持用Alpine作为基础镜像，可以试试这几个方案：

1. 使用conda-forge的预编译包 #

conda-forge社区提供了针对Alpine Linux的预编译科学计算包，用conda安装可以跳过源码编译步骤。你可以在Dockerfile里先安装miniconda，再通过conda安装Pandas和Numpy：

FROM alpine:latest

# 安装依赖并下载miniconda
RUN apk add --no-cache wget bash && \
    wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh && \
    bash Miniconda3-latest-Linux-x86_64.sh -b -p /opt/conda && \
    rm Miniconda3-latest-Linux-x86_64.sh

# 配置conda环境
ENV PATH=/opt/conda/bin:$PATH
RUN conda install -y pandas numpy && \
    conda clean -afy

2. 提前构建带Pandas/Numpy的基础镜像 #

不用每次都在业务镜像里编译，先单独构建一个已经装好Pandas/Numpy的Alpine基础镜像，后续业务镜像直接基于它构建：

# 先构建基础镜像：Dockerfile.base
FROM alpine:latest

RUN apk add --no-cache python3 py3-pip gcc gfortran musl-dev python3-dev openblas-dev && \
    export MAKEFLAGS="-j$(nproc)" && \
    pip install --no-cache-dir pandas numpy

# 构建后推送到镜像仓库，比如docker build -t alpine-pandas:latest -f Dockerfile.base .

# 业务镜像直接用这个基础镜像
FROM alpine-pandas:latest
# 后续只需要添加你的业务代码
COPY ./app /app

3. 优化编译参数加速源码编译 #

如果必须从源码编译，可以通过以下参数利用多核CPU和编译优化：

# 开启多核编译+O3优化
export MAKEFLAGS="-j$(nproc)"
export CFLAGS="-O3 -march=native"
export CXXFLAGS="-O3 -march=native"

pip install --no-cache-dir pandas numpy

三、更合适的替代基础镜像 #

如果对镜像大小的要求不是极端严格，这些镜像可以兼顾轻量和安装速度：

• Python官方slim镜像：基于Debian Slim，使用glibc，PyPI上的预编译wheel都能直接用，安装Pandas/Numpy速度极快，镜像大小比Alpine大一些但远小于标准Debian/Ubuntu。比如python:3.11-slim。
• Debian Slim镜像：直接基于Debian的精简版，搭配Python使用，同样能享受预编译wheel的便利，稳定性也有保障。
• Ubuntu Minimal镜像：Ubuntu的最小化发行版，同样支持glibc和预编译wheel，生态完善。

内容的提问来源于stack exchange，提问作者moku