pip卡在“building wheel”或“resolving packages…”主因是本地依赖解析或c++源码编译，非网络问题；关对进程、手动清缓存目录（如%localappdata%\pip\cache或~/.cache/pip/cache）、禁用杀软实时防护可解决多数情况。
Python安装程序卡在“Building wheel”或“Resolving packages…”不是网络慢，而是 pip 在本地暴力解析依赖或硬编译 C++ 源码——关杀软、清缓存能解决大部分问题，但得关对进程、删对目录。
为什么关杀毒软件有时真有用
Windows 上某些杀软（如 McAfee、360、腾讯电脑管家）会实时扫描 pip 解压的临时文件、.whl 内的 .so/.pyd 文件，甚至拦截 cl.exe 或 g++.exe 的子进程调用。这不是误报，是它们把构建阶段的内存映射、动态链接行为当成了可疑操作。
- 典型现象：安装
dlib或opencv-python时，CPU 占用突然掉到 0%，任务管理器里python.exe状态变成“挂起”或“暂停” - 验证方法：临时禁用实时防护（不是退出杀软），再重试
pip install --verbose dlib，看日志是否恢复输出 - 注意：仅需关实时防护，不需卸载；macOS/Linux 几乎不受影响，不用折腾
清理 pip 缓存必须手动删目录，pip cache purge 不够用
pip cache purge 只清 http 和 selfcheck 子目录，而真正卡住的是 Cache/（旧版）或 http/ 下残留的半成品 .whl、损坏的 METADATA、以及与当前 Python ABI 不兼容的构建中间产物。
- Windows 要删：
%LOCALAPPDATA%\pip\Cache（不是%APPDATA%） - macOS/Linux 要删：
~/.cache/pip/Cache和~/.cache/pip/http（注意大小写，Cache是大写） - 顺手检查：
~/.local/share/virtualenv/（--user安装残留）和虚拟环境下的build/、dist/目录 - 删完别急着重装，先运行
pip cache info确认路径已空
卡在 Building wheel for xxx？大概率是正在编译，不是卡死
比如 opencv-python 卡在 48%，dlib 卡在 “running build_ext”，只要 CPU 满载、内存稳定增长，就是正常编译。PEP 517 构建流程本身不带进度条，终端静默是常态。
- 判断依据：
pip install --verbose opencv-python 2>&1 | grep -i "building\|compiling"（Linux/macOS）；Windows 用pip install --verbose ... > log.txt 2>&1后搜Building - 常见耗时模块：
modules/dnn/（AVX2/AVX-512 优化）、modules/gpu/（CUDA 支持）、dlib/cuda/ - 真卡死信号：CPU ps aux | grep python 显示进程状态为
T（stopped）或长时间无日志输出
最常被忽略的坑：虚拟环境污染 + 错误的 Python 解释器路径
你在终端里敲 pip install dlib，看似在 venv 里，但实际调用的可能是系统 Python 的 pip——尤其当你用 VS Code、PyCharm 或 Conda 激活环境后又开了新终端，或没确认 which python / where python 输出。
- 必查三件事：
python -c "import sys; print(sys.executable)"、pip -V、echo $VIRTUAL_ENV（Linux/macOS）或echo %VIRTUAL_ENV%（Windows） - 如果
sys.executable指向C:\Python39\python.exe，但$VIRTUAL_ENV是D:\venv，说明 pip 装错地方了 - 安全做法：一律用
python -m pip install xxx，确保绑定当前解释器
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
