根本原因是Alpine使用musl libc，而多数PyPI包仅提供glibc预编译wheel；无wheel时需本地编译，但python:3.11-alpine默认缺失gcc、musl-dev等编译依赖，导致报错如“openssl/opensslv.h: No such file or directory”。
直接用 python:3.11-alpine 是最简路径，但 90% 的人会在 pip install 阶段失败或运行时报 ImportError / Segmentation fault —— 根本原因不是 Alpine 本身，而是没处理 musl libc 和编译型依赖的兼容性。
为什么 pip install 在 python:3.11-alpine 里经常失败
Alpine 使用 musl libc，而很多 PyPI 包（如 cryptography、psycopg2、tensorflow、pydantic）默认只提供针对 glibc 的预编译 wheel。没有 wheel 就得本地编译，但 python:3.11-alpine 默认不带 gcc、musl-dev、openssl-dev 等头文件和工具链。
- 现象：构建卡在
Building wheel for cryptography (pyproject.toml): started，最后报fatal error: openssl/opensslv.h: No such file or directory - 错误本质：不是“pip 不行”，是缺少编译依赖 + 缺少 musl 兼容的 wheel 源
- 临时解法（不推荐）：
RUN apk add --no-cache gcc musl-dev openssl-dev libffi-dev—— 这会让镜像体积从 23MB 暴涨到 150MB+，还可能引入运行时冲突
真正轻量又可用的 Alpine 构建方式
核心思路：放弃“在 Alpine 上编译”，改用“在 glibc 环境编译 → 提取 wheel → 在 Alpine 安装 wheel”。这需要多阶段构建 + 信任的 wheel 源。
- 第一阶段用
python:3.11-slim（glibc 环境）安装依赖并生成 wheel：FROM python:3.11-slim AS builderRUN pip wheel --no-deps --no-cache-dir --wheel-dir /wheels -r requirements.txt - 第二阶段用
python:3.11-alpine，只复制 wheel 并离线安装：FROM python:3.11-alpineCOPY --from=builder /wheels /wheelsRUN pip install --no-cache-dir --find-links /wheels --no-index --upgrade --force-reinstall -r requirements.txt - 必须加
--force-reinstall：否则 pip 可能跳过已满足版本但 musl 不兼容的包 - requirements.txt 中避免写死
psycopg2==2.9.7这类无 musl wheel 的版本；优先选带manylinux或musllinux标签的版本（如cryptography>=41.0.0开始提供 musllinux wheel）
哪些包在 Alpine 上根本别碰
不是所有包都值得折腾。有些包即使装上，运行时也会因 musl 行为差异 crash，调试成本远高于换方案。
立即学习“Python免费学习笔记（深入）”；
-
tensorflow：官方 wheel 不支持 musl；用onnxruntime+ ONNX 模型替代更稳 -
pyarrow：musl wheel 极少且版本滞后；改用polars或纯 Python CSV/JSON 处理 -
scipy：编译复杂、依赖 Fortran 工具链；边缘场景建议用numpy+ 手写简单算法 - 如果项目真强依赖这些，别硬扛 Alpine ——
python:3.11-slim（~120MB）已是足够轻量的生产起点，比强行 Alpine 导致上线后 segfault 强得多
Alpine 的 23MB 诱惑很大，但真正的最小化不是看基础镜像大小，而是看「能跑通 + 不出错 + 不返工」的最终镜像体积。多数 Python 服务用 python:3.11-slim + 多阶段构建就能压到 150MB 以内，且省掉三天查 musl 兼容性的时间 —— 这个权衡点，很多人在第一次 docker run 报 Illegal instruction 时才意识到。
