--no-deps仅跳过setup.py或pyproject.toml中声明的依赖安装，无法规避运行时import失败、ABI不兼容或系统级库（如libcudart.so）缺失等问题；适用于已手动安装兼容依赖、离线部署、CI/CD锁定底层C库、容器镜像精简及调试依赖冲突等场景。
不能真正“跳过依赖检查”，--no-deps 只跳过声明式依赖安装，不解决运行时缺失、ABI 不兼容或系统库缺失等问题。
什么时候该用 --no-deps？
它不是万能开关，而是给明确知道后果的人用的工具：
- 你已用
conda或apt装好底层 C 库（比如libgomp.so.1、libcudart.so），想防止 pip 覆盖或降级它们 - 离线环境里所有 wheel 已预下载并校验过依赖关系，只需解包，不需 pip 再解析
- 容器镜像构建中要精简体积，先
pip install --no-deps mypkg，再用apt-get install python3-mypkg-deps - 调试依赖冲突时临时屏蔽某包，确认它是否真是故障源
--no-deps 后 import 还报错，常见原因有哪些？
报 ModuleNotFoundError 或 ImportError 很正常——--no-deps 不负责补漏：
Insightful Pipe
下载
跨40多个平台查询和管理营销数据——Google Analytics、Google Ads、Facebook Ads、Instagram、Shopify、HubSpot、Klaviyo、TikTok、LinkedIn等。
-
ModuleNotFoundError: No module named 'xxx'→ 漏装了间接依赖，比如requests依赖urllib3，但旧 wheel 的setup.py没写全 -
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
怎么知道一个包到底依赖什么？别靠 PyPI 页面猜
PyPI 上显示的 “Dependencies” 常是简化后的结果，不可信。真实依赖藏在元数据里：
- 查已安装包的
pip show package_name输出中的Requires字段（仅对已成功安装的包有效） - 用
python -m pip download --no-deps package_name下载 wheel 后解压，直接读METADATA文件 - 对现代项目，优先运行
pip install build，再用python -m build --wheel --no-isolation构建后 unpack 查依赖 - 注意条件依赖：比如
typing-extensions>=3.7.4; python_version < "3.8"，--no-deps不会跳过这类逻辑
比 --no-deps 更可控的替代方案
硬跳依赖容易翻车，更稳妥的做法是把控制权拿回来：
- 用
pip install --find-links ./wheels --no-index package_name：指定可信 wheel 目录，让 pip 自动解析其元数据里的依赖，而非远程 PyPI - 用
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 package_name，避免编译失败
最常被忽略的一点：有些依赖根本不会出现在 install_requires 里，比如通过 importlib.metadata.entry_points() 动态加载的插件，或运行时调用 subprocess.run(["git"]) 这类外部命令。这类东西只能靠 strace -e trace=openat,open,stat python -c "import mypkg"（Linux）实测捕获，--no-deps 对它们完全无感。
