pipdeptree 4.x：当 pip freeze 不够用时，用这棵依赖树看清你的 Python 环境
一个命令行实用程序，用于显示已安装的 Python 包的依赖关系树。
秒懂
- 它是什么？
- pipdeptree 把 pip freeze 的扁平列表变成带父子关系的依赖树，还能报告冲突、环、许可证和体积。4.x 用 Rust 重写后新增了 from-index 和 from-lock 子命令，让未安装的依赖树也能被检查。
- 适合谁用？
- pipdeptree 适合所有需要理解当前环境依赖关系的 Python 开发者，尤其是维护多个虚拟环境、需要排查依赖冲突或做许可证审计的人。它不适合用来管理依赖版本，也不适合替代 pip-tools 或 uv 这类锁文件生成工具。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
pip freeze 的盲区，正是 pipdeptree 的起点
pip freeze 输出的是一张扁平的包名和版本清单，它不告诉你谁依赖谁。当你面对一个几十个包的环境，想找出某个传递依赖为什么存在，或者想确认升级一个包会牵动哪些下游，扁平列表帮不上忙。pipdeptree 解决的问题就是把这种父子关系画出来。它读取当前环境中已安装的包，构建依赖图，然后以树形结构展示。输出里每个包都标注了 required 和 installed 两个版本，版本不匹配时会有警告符号。这个工具面向的是那些需要理解环境内部结构的开发者，而不是只想知道装了什么的人。
从包元数据到一棵树：机制并不复杂，但细节决定可用性
pipdeptree 的运作方式是读取已安装包的 metadata，也就是每个发行版里的 METADATA 文件，从中提取 Requires-Dist 字段，再把这些关系组装成图。图建好之后，它做两件额外的事：检测依赖冲突，也就是某个包要求的版本范围和实际安装的版本不一致；检测循环依赖，也就是 A 依赖 B、B 又依赖 A 的情况。树形输出只是默认格式，它还能输出 JSON、Mermaid 和 Graphviz SVG。Mermaid 和 Graphviz 的输出意味着你可以把依赖图嵌入文档或生成图片。4.x 版本用 Rust 重写了核心，README 里没有给出性能数字，但从语言选择上可以推断，处理大型环境时的速度比纯 Python 实现要快。
反向查询：从依赖找到它的依赖者
默认的树形输出是从顶层包往下展开，但很多时候你想反着查：某个包被谁依赖。pipdeptree 提供了 --reverse 参数，配合 --packages 可以指定包名。比如 pipdeptree --reverse --packages markupsafe 会列出所有直接或间接依赖 markupsafe 的包。这个功能在排查‘我明明没装这个包，它怎么出现的’这类问题时非常有用。输出格式与正向着完全相同，只是方向颠倒。注意 --packages 接受的是包名，不是版本号，而且它匹配的是包名本身，不是正则表达式。
不安装也能看树：from-index 和 from-lock 子命令
4.x 引入的两个子命令让 pipdeptree 从‘检查已装环境’扩展到‘检查未装环境’。from-index 接受一个包名或 requirements.txt 文件，它会解析依赖并输出树，但不会安装任何东西。from-lock 则读取 PEP 751 格式的锁文件，比如 pylock.toml，完全离线工作。这两个子命令都支持 --summary 和输出格式选项。这意味着你可以在部署前先检查一个 requirements.txt 的依赖树，或者审查一个锁文件的依赖关系，而不必污染当前环境。from-index 需要访问包索引，所以离线环境下它不可用，但 from-lock 不受影响。
摘要模式：把依赖数据变成可读的统计
pipdeptree --summary 会输出一个对齐的文本表格，统计包的数量、依赖深度、冲突数、环数、许可证和安装体积。它提供了三种输出风格：默认的对齐文本、-o rich 的带样式表格、-o json 的机器可读格式。这个功能把依赖树从‘可视化’提升到‘可审计’。许可证信息对于需要合规审查的团队尤其有用，但注意它依赖包元数据里的 License 字段，很多包的这个字段并不规范，所以摘要里的许可证可能不完整。体积信息同样来自 metadata，如果包没有记录安装大小，这一列就会缺失。
Rust 重写的好处与代价
pipdeptree 从 4.x 开始用 Rust 实现核心逻辑，这带来了两个直接变化：启动速度和内存占用。Python 工具启动时解释器加载本身就慢，Rust 编译出的二进制几乎瞬间启动。对于 CI 脚本里频繁调用 pipdeptree 的场景，这个差异是实打实的。代价是安装方式变了，pip install pipdeptree 现在安装的是一个 Rust 二进制，而不是 Python 包。这意味着它不再像纯 Python 工具那样天然支持所有平台，你需要检查项目是否提供了对应平台的 wheel。另外，如果你依赖 pipdeptree 的 Python API 来编程调用，4.x 可能不再暴露同样的接口，因为核心已经变成 Rust。README 里没有提到 Python API 的兼容性，这一点需要查阅文档确认。
与 pip check 和 pip-tools 的定位差异
pip check 也能报告依赖冲突，但它只输出冲突列表，不展示树。pipdeptree 的优势在于把冲突放在上下文中，你能看到冲突发生在哪个分支。pip-tools 是另一个常用工具，它负责生成锁文件，pipdeptree 不生成锁文件，它只解析和展示。两者可以配合使用，pip-tools 生成 requirements.txt 的锁定版本，pipdeptree 分析这个锁定版本的依赖结构。注意 pipdeptree 的 from-lock 读取的是 PEP 751 格式，而 pip-tools 默认输出的是 pip freeze 风格的 requirements.txt，两者并不直接兼容。如果你已经在用 uv，它的 lock 文件也是 PEP 751 格式，那么 pipdeptree from-lock 可以直接读取，省去转换步骤。
维护状态与许可证
pipdeptree 的仓库托管在 tox-dev 组织下，最近一次提交是 2026 年 8 月，4.2.2 版本于同一天发布，说明项目处于活跃维护状态。许可证是 MIT，这意味着你可以自由使用、修改和分发，只要保留版权声明。对于企业用户来说，MIT 许可证没有传染性，不会影响你的专有代码。维护成本方面，pipdeptree 依赖 Python 包的 metadata 格式，而 Python 的打包规范仍在演进，比如 PEP 751 就是新标准，所以你需要跟上新版本以支持最新的元数据格式。升级时要注意 4.x 的 Rust 核心可能带来行为变化，建议在升级后跑一遍 --summary 确认输出符合预期。
编辑结论
pipdeptree 适合所有需要理解当前环境依赖关系的 Python 开发者，尤其是维护多个虚拟环境、需要排查依赖冲突或做许可证审计的人。它不适合用来管理依赖版本，也不适合替代 pip-tools 或 uv 这类锁文件生成工具。如果你要采纳它，先确认两件事：一是你的 Python 版本是否在支持范围内，二是 from-index 子命令依赖网络索引，离线环境下只能靠 from-lock 读取 PEP 751 锁文件。4.x 的 Rust 核心让它在大型环境中比旧版快得多，但如果你只是偶尔看一眼依赖，pip 自带的 pip check 加上 pip freeze 可能已经够用。
社区笔记