根本原因是环境不一致或版本冲突，如在Python 3.9环境生成的requirements.txt直接用于3.11环境易因包不兼容失败；pip freeze导出全部包（含间接依赖）导致锁定过死，推荐用pipreqs按代码import生成精简依赖；条件语法（如python_version >= "3.9"）和-e .、git+https等写法破坏可复现性，应避免。
requirements.txt 生成后为什么 pip install 总是报错？
根本原因通常是环境不一致或版本冲突。比如你在 Python 3.9 虚拟环境中用 pip freeze > requirements.txt 生成的文件，拿到 Python 3.11 环境里直接 pip install -r requirements.txt，很可能因包不兼容失败。
- 务必在目标运行环境（或相同 Python 版本+系统）中生成和安装
- 避免用
pip freeze导出全部包——它会包含你没直接依赖的间接依赖（如urllib3、idna），导致锁定过死 - 推荐用
pipreqs：只扫描项目代码中的import，生成更干净的依赖列表：pip install pipreqs<br>pipreqs ./ --encoding=utf8 --force
如何让 requirements.txt 支持不同环境（dev / prod）？
硬写两个文件最稳妥，别试图用条件语法（如 pkg; python_version >= "3.9"）搞复杂逻辑——pip 对它的支持有限，CI/CD 中容易出错。
- 拆成
requirements.txt（生产依赖）和requirements-dev.txt（开发依赖） - 在
requirements-dev.txt开头用-r requirements.txt复用生产依赖，再追加pytest、black等 - 安装时明确指定：
pip install -r requirements-dev.txt，而不是靠注释或 README 提醒
版本号写法怎么选：==、>= 还是不写？
不写版本号（如 requests）最危险——下次 pip install 可能拉取不兼容的大版本；写死 ==2.28.2 又难维护。折中方案更实用：
- 核心库（
django、flask、numpy）用~=：如django~=4.2.0表示允许 4.2.x 升级，但不跨 4.x → 5.x - 工具类（
black、mypy）用>=+ 最小可用版，例如black>=23.10.0 - 绝对避免在生产环境用
*或空版本，CI 流水线会因上游更新突然崩掉
为什么 requirements.txt 里不该出现 -e . 或 git+https 链接？
这些写法会让 pip install -r 直接从源码安装，破坏可复现性：git commit hash 可能被 force push 覆盖，本地路径 -e . 在其他机器上根本不存在。
立即学习“Python免费学习笔记（深入）”；
- 如果必须依赖私有包，先发布到私有 PyPI（如 Nexus、Artifactory），再用
index-url配置源 - 临时调试可用
pip install -e /path/to/local/package，但不要提交进requirements.txt - CI 构建阶段若需特定分支，应通过构建参数传入 commit hash，而非固化在 requirements 中
真正麻烦的不是生成文件，而是每次部署前没人检查 pip list 和 requirements.txt 是否一致——建议在 CI 中加一步验证：pip install -r requirements.txt && pip freeze | grep -v "pkg-resources" | sort > frozen.txt && diff -q requirements.txt frozen.txt。
