pip-autoremove 不会彻底清理孤立包，它仅删除被 pip 明确标记为“非显式安装且未被任何现存包依赖”的包；不扫描代码、不读 requirements.txt、不处理 conda/本地安装包，且默认将 pip、setuptools、wheel 列入候选，直接 -y 可能导致环境瘫痪。
pip-autoremove 不会“彻底清理孤立包”，它只删那些被 pip 明确标记为「非显式安装 + 未被任何现存包依赖」的包——而绝大多数环境压根没生成过这种标记，所以直接 pip-autoremove -y 很可能啥也不删，或误删 pip、setuptools 导致环境瘫痪。
pip-autoremove 删哪些包？看它怎么判定“孤立”
它不扫描你的 .py 文件，不读 requirements.txt，也不管你代码里有没有 import torch。它只查 pip 内部元数据：
-
pip install flask→werkzeug和jinja2被记为 flask 的依赖，不删 -
pip install jinja2单独装过 →jinja2变成“显式安装”，哪怕 flask 卸载了，它也不会被删 -
pip install -e .或python setup.py install装的包 → 完全跳过，不进分析范围 - 手动删过
site-packages里的文件但没走pip uninstall→ 元数据损坏，变成“幽灵包”，它直接忽略（但它们还在占空间）
为什么 pip-autoremove -y 执行完还剩一堆包？
这不是 bug，是设计限制。以下情况它直接失效：
- 项目用
poetry或pipenv管理 → 它只看pip list输出，感知不到 lock 文件约束 - 环境是
conda创建的 → 对 conda 安装的包无效，且可能误删混装的 pip 包 - 装过
setuptools、wheel、pip自身 → 它默认把它们列进候选，-y就等于主动废掉包管理能力 - 用
pip install --find-links或离线安装 →pip show缺失Requires-Dist字段，依赖链断裂
真正能落地的清理组合操作
别把它当主力工具，只适合小范围收尾。更靠谱的路径是：
- 先运行
pipreqs ./ --force --savepath requirements_real.txt，扫描真实import行为生成最小依赖清单 - 执行
pip freeze > requirements_all.txt，再用comm -23 找出未被 import 的包 - 人工过滤掉
pip、setuptools、wheel、pip-tools等关键包，再pip uninstall -y -r unused.txt - 如果环境已严重污染，
rm -rf venv && python -m venv venv && pip install -r requirements_real.txt反而更快
最容易被忽略的一点：pip-autoremove 在虚拟环境中默认把 pip 自己列为可删项
它在 venv 里运行时，pip、setuptools、wheel 都出现在候选列表里。不加 -l 就直接 -y，等于亲手卸载自己的包管理器。务必先跑 pip-autoremove -l 看一眼列表，手动确认再操作——尤其当你不确定这个环境是否混装了 conda 包或本地开发包时。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
