不会。pip uninstall 默认只卸载显式指定的包，不删除其子依赖，因pip无法判断子依赖是否被其他包共用，故采取保守策略避免误删导致其他包崩溃。
pip uninstall 会自动删子依赖吗
不会。pip uninstall 默认只卸载显式指定的包，完全不触碰它的子依赖（即被其他包共用的依赖）。这是设计使然——pip 无法判断某个子依赖是否还被别的包需要，所以选择保守策略，避免误删导致其他包崩溃。
常见错误现象：pip uninstall requests 后，urllib3、chardet 这些仍留在环境中；更隐蔽的问题是，如果后续装了另一个也依赖 urllib3 的包，它可能因版本冲突或重复安装出问题。
- 使用场景：清理已弃用项目依赖、修复因依赖污染导致的导入错误、准备干净环境做迁移
- 关键限制：pip 没有内置“递归卸载且验证残留”的功能，不能靠一条命令解决
- 性能影响：手动检查依赖树耗时，但比运行时报
ImportError或VersionConflict更可控
如何查清一个包到底带哪些子依赖
用 pip show 看直接依赖，再用 pipdeptree 查完整依赖树。后者不是 pip 内置命令，需先装：pip install pipdeptree。
例如查 requests 的依赖链：pipdeptree --packages requests 输出类似：
立即学习“Python免费学习笔记（深入）”；
安全 Python 代码沙箱：在隔离的沙箱中执行任意 Python 代码，预装 requests、NumPy、pandas 库。返回 stdout、stderr。
requests==2.31.0 └── charset-normalizer [required: >=2.0.0,<4.0.0, installed: 3.3.2] └── idna [required: >=2.5,<4, installed: 3.7] └── urllib3 [required: >=1.21.1,<3, installed: 2.2.1] └── certifi [required: >=2017.4.17, installed: 2024.2.2]
注意：pipdeptree --reverse --packages urllib3 可反查谁在用 urllib3，这是判断能否安全卸载的关键步骤。
- 容易踩的坑：直接看
pip show requests只显示顶层依赖，漏掉间接依赖（比如urllib3可能被httpx也引用） - 参数差异：
--warn silence可屏蔽警告，但建议首次运行不加，便于发现循环依赖或缺失包 - 兼容性：
pipdeptree在 Python 3.8+ 行为稳定；若用 pyenv 或 conda，确保它在当前激活环境中运行
安全卸载的实操流程（不破坏其他包）
核心逻辑：先确认子依赖未被其他包使用，再逐个卸载，最后验证。
- 执行
pipdeptree --reverse --packages <子依赖名>，若输出为空或只有你要卸载的主包，则该子依赖可删 - 按依赖树从底向上卸载（先删
certifi，再删urllib3……），避免卸载中途报错中断 - 每卸一个包后，用
pip list | grep <包名>确认已移除；再跑一次pipdeptree --packages <主包名>看是否还有残留 - 卸载完成后，建议运行
pip check，它会报出所有未满足的依赖约束（如某包声明需要requests>=2.25.0但已被删）
示例：想彻底清除 flask-restx 及其独占依赖：
pipdeptree --reverse --packages werkzeug # 看是否只有 flask-restx 在用 pip uninstall werkzeug click itsdangerous # 先卸这些，再卸 flask-restx pip check
virtualenv 是唯一真正安全的卸载前提
在全局 Python 环境或系统 site-packages 里硬删依赖，风险极高。哪怕你确认某个子依赖“没人用”，也可能被 pip 自己或其他工具（如 setuptools、pip-tools）内部调用。
真实项目中，几乎所有的“卸载后出问题”都源于没隔离环境。conda 用户同理：不要在 base 环境操作，用 conda create -n clean-env python=3.11 新建后再装所需包。
- 容易被忽略的点：IDE（如 PyCharm）可能缓存旧的包路径，卸载后需重启解释器或刷新项目 SDK
- CI/CD 场景下，应固定
requirements.txt并用pip install --force-reinstall -r requirements.txt替代手动卸载 - 如果你在容器里，直接重写
Dockerfile的RUN pip install行，比进容器里卸载更可靠
