Deptry 依赖审计器

依赖声明为什么会悄悄失真

Python 项目的依赖清单很少能一劳永逸。一次顺手的 pip install、一段实验性质的导入、一个仅因传递关系而存在的包——这些操作都不会自动更新 pyproject.toml 或 requirements.txt。等到发布前再回头看，清单里往往躺着早已没人 import 的包，而真正被用到的模块却可能压根没声明，只能依赖间接依赖侥幸生效。这类偏差在单人小项目里只是难看，在多人协作或长期维护的仓库里，就是构建不可复现、安全审计翻车的伏笔。

发布前跑一轮静态审计

这个技能的核心做法是把 Deptry 当作发版前的例行检查：扫描整个代码库的实际导入，与项目声明的依赖逐条对照，再把差异分成三类：

• 未使用的直接依赖：声明了却没有任何代码 import 的包；
• 缺失的声明：代码在用、但清单里没有的包；
• 仅靠传递关系生效的导入：实际来自某个依赖的间接依赖，上游一收紧就可能崩。

技能把发现整理成两类输出：可以顺手清理的项，转化为 cleanup 提交；真正影响交付的项，直接作为发布阻止项拦下来，逼你在版本出去之前把账对平。

适用边界与注意点

• 仓库需已配置 Deptry，且运行环境有可用的 Python 与包管理器解析元数据，否则扫描结果可能不完整。
• 静态分析只看字面导入，动态加载（如 importlib 按字符串导入）可能被漏判，必要时需人工复核。
• 它解决的是声明与代码的一致性问题，不替代漏洞扫描或许可证合规检查，重要项目仍建议配合专用工具使用。