根本解法是多阶段构建：第一阶段用含编译工具的基础镜像安装numpy并清理缓存，第二阶段用精简镜像仅复制运行所需文件，同时删除测试、文档等非必要内容，并显式安装openblas运行时库。
NumPy 本身不重，但它的编译依赖（如 OpenBLAS、LAPACK、gcc）和 wheel 兼容性问题，会让它在 Docker 镜像里“悄悄胖起来”——尤其当你用错基础镜像或没做阶段分离时，一个只导入 numpy 的服务镜像可能飙到 600MB+。根本解法不是删 NumPy，而是不让编译环境进最终镜像。
为什么 NumPy 安装后镜像体积暴增？
常见错误现象：pip install numpy 后镜像比预期大 300MB 以上；docker history your-image 显示某层体积异常高；运行时 import numpy 没问题，但构建阶段残留了 /usr/lib/gcc 或 /usr/include 等整套编译树。
- NumPy 默认会尝试编译优化版本（尤其是带 OpenBLAS 支持的 wheel），需要
build-essential、libopenblas-dev等系统级依赖 - 这些依赖被
RUN apt-get install装进去后，即使后续apt-get remove，Docker 分层机制也保留了原始安装包数据 - Alpine 镜像上
numpy往往被迫源码编译（musl libc 不兼容预编译 wheel），耗时长且产物更臃肿 - 未启用
--no-cache-dir时，pip 缓存（/root/.cache/pip）会固化进镜像层
多阶段构建中 NumPy 的正确安装姿势
核心原则：编译归编译，运行归运行。NumPy 的二进制 wheel 只需复制 site-packages/numpy 目录，其余全是累赘。
- 第一阶段（builder）用
python:3.11-slim-bookworm（非 Alpine），装build-essential libopenblas-dev和pip install --no-cache-dir numpy - 避免在 builder 阶段创建虚拟环境再激活——直接用系统 Python 安装，路径明确，复制可控
- 第二阶段（runner）用同版本
python:3.11-slim-bookworm，COPY --from=builder /usr/local/lib/python3.11/site-packages/numpy /usr/local/lib/python3.11/site-packages/numpy - 如果项目还依赖
scipy或pandas，把它们和numpy一起装在 builder 阶段，统一复制整个site-packages子集（用COPY --from=builder /usr/local/lib/python3.11/site-packages/ /usr/local/lib/python3.11/site-packages/）
容易被忽略的 NumPy 体积陷阱
你以为复制完就完了？这几个点不处理，体积照样虚高：
-
numpy安装后默认带测试数据和文档（numpy/testing,numpy/doc），用RUN find /usr/local/lib/python3.11/site-packages/numpy -name "testing" -o -name "doc" | xargs rm -rf清理 - OpenBLAS 运行时库（
libopenblas.so.*）会被numpy动态链接，但不会自动复制进 slim 镜像——第二阶段必须apt-get install -y libopenblas0（注意是libopenblas0，不是libopenblas-dev） - 若用
pip install --only-binary=numpy强制跳过编译，需确认对应平台 wheel 是否存在（manylinux_2_17或manylinux2014），否则 pip 仍会 fallback 到源码编译 -
pip install numpy默认带setuptools和wheel，它们对运行无用，可在 builder 阶段末尾pip uninstall -y setuptools wheel
真正关键的不是“怎么装 NumPy”，而是“谁来装、在哪装、装完留什么”。多阶段构建不是魔法，它只负责隔离——你得清楚告诉 Docker：编译器、头文件、缓存、文档，全留在 builder 里别出来。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
