pip freeze > requirements.txt 不可重现环境，因它包含所有间接依赖；应使用 requirements.in + pip-compile 生成带哈希的 requirements.txt，并分离 dev/test 依赖，避免硬编码源地址。
pip freeze > requirements.txt 为什么不能直接用
它会把所有依赖（包括间接依赖）全塞进去，导致环境不可重现。比如你只装了 requests，pip freeze 却会列出 urllib3==1.26.18、charset-normalizer==3.3.2 这类子依赖，而它们的版本可能随时间变动或被其他包升级覆盖。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
pip install -e .（配合setup.py或pyproject.toml）管理顶层依赖，再用pip-compile生成锁定文件 - 若不用工具链，至少手动维护顶层依赖：只写
requests>=2.28.0、click~=8.1.0这类你明确需要的包 - 避免在
requirements.txt里写死间接依赖版本——除非你真遇到了兼容性问题且已验证过
什么时候该用 requirements.in 而不是直接改 requirements.txt
当你需要区分「我写的依赖」和「实际安装的依赖」时。requirements.in 是人类可读、可维护的输入文件；requirements.txt 是机器生成、带完整版本号的输出文件，用于 CI 或部署。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 把
requests>=2.28.0、django~=4.2.0写进requirements.in - 运行
pip-compile requirements.in生成requirements.txt（含哈希值和所有传递依赖） -
git add requirements.in && git commit，但requirements.txt每次变更都要提交——它是部署事实依据 - CI 中用
pip install --require-hashes -r requirements.txt强制校验完整性
dev 依赖、测试依赖怎么放进 requirements 体系
不要全堆进主 requirements.txt。否则生产环境也会装上 pytest 和 mypy，增加攻击面和构建体积。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 建
requirements-dev.in，内容以-r requirements.in开头，再追加pytest>=7.0、mypy - 用
pip-compile requirements-dev.in生成requirements-dev.txt - 本地开发用
pip install -r requirements-dev.txt；docker 或线上只装requirements.txt - 如果项目用
pyproject.toml，更推荐用[project.optional-dependencies]定义dev、test等分组
requirements.txt 里的 –index-url 或 –find-links 该怎么处理
这些是 pip 的源配置，不属于依赖声明本身。硬编码进 requirements.txt 会导致换环境（比如从内网到 github Actions）时 pip 找不到包。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 删掉
requirements.txt里所有--index-url、--find-links行 - 改用
pip.conf（linux/macOS）或pip.ini（windows）统一配置源，或传参pip install -i https://pypi.tuna.tsinghua.edu.cn/simple/ -r requirements.txt - 私有包必须用
--find-links？那就单独建requirements-private.in，并在 CI 脚本中显式传参，不污染主依赖流
真正麻烦的是跨团队协作时对「谁负责更新 requirements.txt」没共识，以及忘记在 PR 中同步更新锁定文件。只要有人绕过 pip-compile 直接改 requirements.txt，整个版本控制就失效了。