requirements.txt是python项目环境复现的强制标准，通过pip install -r requirements.txt逐行安装精确版本（如numpy==1.24.3）实现跨机器一致性；它必须手动维护最小依赖集并杜绝模糊版本（如flask）或pip freeze快照式生成，否则将引发环境漂移与协作故障。
requirements.txt 不是“推荐用”，而是实际项目中必须用——它解决的是「换台机器就跑不起来」这个最痛的问题。
pip install -r requirements.txt 为什么能复刻环境？
因为 pip install -r requirements.txt 不是模糊安装，而是按行逐条执行精确指令：
- 每行是一个
包名==版本号（如numpy==1.24.3），pip 会强制安装该确切版本，跳过任何兼容性判断 - 没有版本号的行（如
flask）虽能装，但会导致环境漂移，生产环境应杜绝 - 它不关心你本地有没有其他包，只管把文件里写的全装上，干净虚拟环境 + 这个命令 = 可预期结果
注意：pip freeze > requirements.txt 生成的是当前环境快照，但会包含开发时顺手装的调试工具（比如 ipdb、black），直接提交会导致别人也装一堆无关包。
为什么不能只靠 pip freeze 自动生成？
pip freeze 输出的是「所有已安装包」，不是「项目真正需要的包」。常见陷阱包括：
- 你在虚拟环境中试过
scrapy又卸载了，但它可能还残留依赖（如twisted）在pip freeze结果里 - 你用
conda装过基础科学包，再用pip装项目依赖，pip freeze会混入 conda 管理的包（如mkl、ca-certificates），这些无法用pip install安装 - 有些包通过
git+https://...安装，pip freeze会输出带哈希的长 URL，换环境后可能因网络或权限失败
所以更稳妥的做法是：先手动整理最小依赖集，再用 pip install -r requirements.txt 验证能否从空环境跑通。
requirements.txt 中的 ~=、>=、== 版本写法影响什么？
版本约束符不是风格问题，它直接影响部署稳定性：
-
requests==2.28.1：锁死，最安全，CI/CD 和生产环境首选 -
requests~=2.28.0：等价于>=2.28.0, ，允许补丁更新（如 2.28.2），适合开发阶段快速获取安全修复 -
requests>=2.25.0：风险最高，可能拉到 2.30.x，而你的代码依赖已废弃的urllib3接口，运行时报AttributeError
如果你看到 flask 这种没版本号的写法，基本可以判定这个 requirements.txt 是随手导出没清理过的——它会让不同时间安装的人拿到完全不同的 flask 版本，连路由注册行为都可能不一致。
多人协作时，requirements.txt 最容易被忽略的细节
团队里最常出问题的不是语法，而是「谁负责更新」和「什么时候更新」：
- 有人改了代码，加了
pydantic，但忘了更新requirements.txt→ 新人 clone 后import报错 - 有人本地
pip install -U升级了一堆包，然后直接pip freeze > requirements.txt提交 → 整个项目依赖突然跨大版本，测试全挂 -
requirements.txt没进.gitignore，但里面写了-e ./src这种本地路径 → 别人 clone 下来直接 pip 报错
真正可靠的流程是：每次新增依赖，先 pip install 包名，再手动追加一行 包名==版本号 到 requirements.txt，最后用干净虚拟环境验证 pip install -r requirements.txt 是否真能跑通。这多花的两分钟，省下的是一整天排查环境问题的时间。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
