我要评论pipreqs更靠谱因其仅扫描源码中实际import的包，避免混入未使用的全局包；而pip freeze导出全部已安装包，易导致部署失败或ci冲突。
pipreqs 生成 requirements.txt 为什么比 pip freeze 更靠谱
因为 pipreqs 只扫描项目源码中实际 import 的包，不会把全局环境里装了但没用到的包也塞进 requirements.txt。而 pip freeze 是照单全收当前环境所有已安装包，尤其在虚拟环境管理不严时，容易混入开发依赖、临时调试工具甚至系统级包。
常见错误现象：pip freeze > requirements.txt 导出后部署失败，报错说某个包根本没被项目引用；或者 ci 流水线因多余依赖冲突卡住。
- 适用场景：新项目初始化、交接给他人、准备 docker 构建、提交前自查依赖
- 不适用场景：想导出包括 pytest、black 这类纯开发依赖——pipreqs 默认忽略它们（需额外参数）
- 注意：它不解析 setup.py 或 pyproject.toml，只看 python 源文件里的 import 语句
安装和基础命令怎么跑起来
先确保没和旧版 pipreqs 冲突（老版本有路径 bug）：
pip install --upgrade pipreqs
进到项目根目录（含 src/ 或 app.py 等源码的那层），执行：
pipreqs ./
它会自动扫描所有 .py 文件，生成 requirements.txt。如果提示 filenotfounderror: no such file or directory: 'requirements.txt'，说明文件已存在且被锁——删掉再试，或加 --force。
- --encoding=utf-8：遇到中文注释或路径时报 unicodedecodeerror 时必加
- --diff requirements.txt：对比现有文件，只输出新增依赖（适合增量更新）
- --savepath ./reqs-dev.txt：指定输出路径，避免覆盖主文件
怎么让 pipreqs 扫描子目录和识别动态导入
默认情况下，pipreqs 只扫当前目录及直接子目录，遇到 src/mylib/ 或 apps/api/ 这类结构会漏掉。必须显式指定路径：
pipreqs ./src ./apps --force
但它无法识别字符串拼接式导入（如 __import__(f"{name}_plugin")）或 importlib.import_module() 动态加载——这类依赖得手动补进 requirements.txt。
- 常见坑：django 项目里 installed_apps 列表中的第三方 app（如 'django-crispy-forms'）不会被自动识别，必须人工核对添加
- 若用 setuptools 的 entry_points 或插件机制，pipreqs 也无能为力
- 建议搭配 grep -r "import\|from.*import" . --include="*.py" 快速扫一遍可疑模块名
生成结果不准？先检查 import 语句写法
pipreqs 解析的是字面量 import，不是运行时行为。所以这些写法会导致漏依赖：
- import requests as req → 能识别 requests
- import mypkg.utils → 只认 mypkg，不会深挖 utils 依赖的其他包
- from . import config 或 from ..models import user → 相对导入只影响模块查找，不引入新第三方包，没问题
- try: import ujson except importerror: import json → ujson 会被识别，即使实际运行走的是 json
真正容易被忽略的是条件导入 + 第三方包组合，比如 if sys.version_info >= (3, 9): from importlib import resources else: import importlib_resources as resources——pipreqs 会把两个都列进去，你得自己删掉不生效的那个。
到此这篇关于python中pipreqs自动生成项目依赖清单的实现的文章就介绍到这了,更多相关python pipreqs自动生成依赖清单内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论