在开发ref="/tag/136/" style="color:#479099;font-weight:bold;">Python项目时，依赖管理是个绕不开的问题。很多人用pip install装完库就直接开工，等到换机器或者团队协作时才发现别人跑不起来代码。这时候一个写得好的requirements.txt就能救场。
别再手敲pip freeze > requirements.txt了
新手常犯的一个错误就是项目一开始就把所有环境里的包导出一遍。比如你本地装了Django、Flask、requests还有一堆调试工具，一执行pip freeze > requirements.txt，结果把IPython、jupyter、pytest全塞进去了。等部署到生产服务器，不仅安装慢，还可能引入安全风险。
正确的做法是分环境管理依赖。如果你做的是Web项目，可以像这样组织：
# requirements/base.txt
Django==4.2.7
requests==2.31.0
Pillow==10.0.1
# requirements/dev.txt
-r base.txt
pytest==7.4.3
flake8==6.1.0
ipdb==0.13.13
# requirements/prod.txt
-r base.txt
gunicorn==21.2.0
固定版本号，但要有策略
写requirements.txt最怕的就是“在我电脑能跑”。所以每个包都要写具体版本号，避免今天能运行明天报错。但也不能太死板，比如requests==2.31.0没问题，可要是连小版本都锁死到2.31.0，以后安全更新都推不进去。
建议主版本锁定，允许小版本自动升级：
requests>=2.31.0,<3.0.0
Django>=4.2.0,<5.0.0
这样既能保证兼容性，又能吃到官方的安全补丁。
加上注释说明用途
时间久了谁也记不住为啥要装某个包。特别是团队项目里，新来的同事看到cryptography==41.0.3可能会懵。加一行注释花不了几秒，但能省下后面半小时沟通成本。
# 用于处理微信支付签名验证
cryptography==41.0.3
# 生成PDF报表使用
reportlab==4.0.4
定期更新并测试
别把requirements.txt当成一次性文件。就像手机APP要更新一样，第三方库也会发新版修漏洞。可以每个月抽半天时间，用pip list --outdated看看有没有可更新的包，然后在测试环境跑一遍再上线。
有个实际例子：之前有项目用了旧版urllib3，没多久就被扫描出CVE漏洞，被迫停服紧急修复。如果平时有更新习惯，这种问题完全能提前避开。
最后提交到代码仓库
写好了别忘了git add requirements/ && git commit -m "update dependencies"。不然同事拉代码还得一个个问你装什么，客户部署时更是各种报ModuleNotFoundError。
一个清晰、合理、带版本控制的依赖清单，不只是技术细节，更是项目靠谱程度的体现。特别是在涉及用户数据和网络请求的场景下，管好这些依赖，等于给自己的应用多穿一层防护衣。