执行安装命令后，输出停在 Building wheel for xxx 那一行，进度条半天不动。这时候先别急着杀进程，先分清它是在真干活，还是在等一个永远不会返回的调用。
先判断卡住的原因
往上翻输出，如果下载到的是 .tar.gz 而不是 .whl，说明这个包没有适合你平台的预编译包，pip 只能拿源码现场编译。再开个终端看进程的 CPU 占用：一直吃满一个核，就是编译确实慢，等它跑完即可；CPU 几乎为零，多半是构建脚本在联网拉取子依赖，网络不通才挂住的。
优先找预编译包
旧版 pip 可能不认识较新的打包规范，导致明明有包却识别不了。先升级再安装：
python -m pip install --upgrade pip pip install --only-binary :all: 包名
加 only-binary 参数可以强制只用预编译包，没有就直接报错，而不是默默进入漫长的源码编译。报错信息会明确告诉你哪个平台、哪个版本没有对应的包，比卡着强。
确实是缺系统依赖
常见的数据库驱动、图像和 XML 库编译时要读 C 头文件，系统里没装就反复失败或卡住。以 Debian 系为例：
apt-get install -y python3-dev build-essential apt-get install -y libpq-dev # PostgreSQL 驱动 apt-get install -y libxml2-dev libxslt-dev # lxml
CentOS 系把包名换成 python3-devel 和对应的 -devel 包即可。装完头文件，重新执行安装，通常几十秒就过。
装完怎么确认走了捷径
成功的输出里会出现 Using cached xxx.whl 字样，说明直接复用了预编译包，完全跳过编译。如果日志里仍出现 Building wheel，说明这个版本在你环境下依然只能源码编译，可以考虑换一个有预编译包的版本号，而不是在老版本上死磕。
容器里装依赖时把这组系统包装进镜像的基础层，后续构建就不会再在这个环节反复浪费时间。