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 等源码的那层），执行：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
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 会把两个都列进去，你得自己删掉不生效的那个。
