pip install --no-deps 仅跳过 setup.py 或 pyproject.toml 中声明的依赖安装，无法规避运行时 import 失败、abi 不兼容或系统级库缺失等问题；它适用于已手动装好兼容依赖、离线部署或调试依赖冲突等可控场景。
pip install --no-deps 只跳过 setup.py 或 pyproject.toml 中声明的依赖安装，无法绕过运行时 import 失败、ABI 不兼容、系统级共享库（如 libcudart.so）缺失等问题。
什么时候 --no-deps 真的有用
它不是“跳过所有依赖”的万能开关，而是针对特定可控场景的窄口径工具：
- 你已用
conda或其他方式手动装好全部兼容依赖（比如numpy==1.24.4+scipy==1.11.4），想防止 pip 降级或覆盖 - 离线部署环境，所有 wheel 已预校验并放在本地目录，只需解包不解析
- 调试加载失败原因，临时屏蔽某个疑似冲突依赖（如
pip install --no-deps requests看是否还报urllib3相关错）
注意：--no-deps 不检查版本兼容性，也不跳过带环境标记的条件依赖（如 typing-extensions>=3.7.4; python_version ）——这部分仍会被忽略，除非你额外加 <code>--no-build-isolation 并自定义构建环境。
用了 --no-deps 还报错？先查这三处
常见错误不是 --no-deps 失效，而是你没意识到它根本管不了这些事：
-
ModuleNotFoundError: No module named 'xxx'→ 漏装了间接依赖（比如某 wheel 元数据没完整声明idna是requests的依赖） -
ImportError: libc.musl-x86_64.so.1: cannot open shared object file→ musl vs glibc 二进制不兼容，和 pip 参数无关，得换对应平台的 wheel -
AttributeError: module 'pkg_resources' has no attribute 'get_distribution'→setuptools版本太低，--no-deps让它没被升级，需单独pip install -U setuptools
比 --no-deps 更稳妥的替代方案
直接甩开依赖容易翻车，以下做法对生产环境更可控：
- 用
pip install --find-links ./wheels --no-index package_name：指定可信 wheel 目录，让 pip 自动读取其元数据里的依赖关系，而非远程拉取 - 用
pip install --force-reinstall --no-deps package_name：只重装主包，不动已有依赖，适合热更新核心模块 - 在
requirements.txt中写死基础依赖版本（如numpy==1.24.4），再用pip install -r requirements.txt --no-deps分步装：先跑一遍基础库，再装上层包 - 对纯 C 扩展包（如
lxml），优先pip install --only-binary=all lxml，避免因缺失libxml2-dev等系统头文件导致编译失败
真正难处理的从来不是 pip 参数本身，而是你是否清楚哪些依赖是 Python 层声明的、哪些是运行时硬绑定的、哪些来自操作系统——--no-deps 只碰得到第一类。
