requirements.txt 最佳写法
在 Python 项目中，requirements.txt 是管理依赖的核心文件。写得不好，轻则别人跑不起来你的代码，重则线上环境出问题。别觉得这只是一个列表文件就随便写，细节决定成败。
明确版本号，避免“我本地能跑”
很多人图省事，直接 pip freeze > requirements.txt，结果一堆带具体版本的包，还夹杂着你开发时顺手装的 ipython、pytest。这种文件丢给同事，人家只想关掉终端去喝咖啡。
正确的做法是只列出项目真正依赖的核心包，并固定主要版本。比如：
django>=4.2,<5.0
requests>=2.28.0,<3.0.0
celery[redis]>=5.2.0,<6.0.0这样既保证了兼容性，又不会因为某个小版本更新导致破坏性变更。
分环境管理依赖
开发、测试、生产用同一份依赖？那你的镜像体积可能比代码还大。建议拆分成多个文件：
# requirements/base.txt
django>=4.2,<5.0
requests>=2.28.0,<3.0.0# requirements/dev.txt
-r base.txt
pytest==7.4.0
ipdb==1.5.0
flake8==6.0.0# requirements/prod.txt
-r base.txt
gunicorn==21.2.0
psycopg2-binary==2.9.7通过 -r 引入共用部分，清晰又不重复。部署时只装 prod，CI 跑测试时装 dev，谁用谁知道。
带上注释，别让同事猜谜
有些包的作用不是一眼能看出来的。比如你用了 django-cors-headers，新来的同事可能不知道为啥要这个。加个注释就行：
# 用于解决前端本地开发时的跨域请求问题
django-cors-headers==4.3.1几秒钟的事，能省下半小时解释时间。
避免使用 pip freeze 直接输出
pip freeze 适合生成最终锁定版本，不适合直接当依赖清单用。它会把所有间接依赖都列出来，包括你根本没主动装过的。
正确流程是：先手动写 requirements/base.txt，再用 pip install -r 安装，最后在发布前用 pip freeze > requirements.lock.txt 锁定全量版本。这样 base 管意图，lock 管确定性。
考虑使用替代工具
如果你觉得 txt 文件太原始，可以试试 Poetry 或 Pipenv。但大多数团队还是用 requirements.txt，简单直接。
哪怕不用新工具，也可以学它们的思路——把依赖分组、加描述、做锁文件。这些东西不花多少时间，但能让协作顺畅很多。
一个写得好的 requirements.txt，就像一份清晰的菜单：你知道点了啥，大概多少钱，有没有忌口。别让别人打开你的项目，像拆盲盒一样提心吊胆。