最轻量、最可控、也最容易被 CI/CD 接入的方式是用 requirements.in + pip-compile 分层生成不同环境的锁定文件，因其实现声明与锁定分离、支持环境标记、哈希校验、自动依赖解析及 pip-sync 精确同步。
直接说结论：用 requirements.in + pip-compile 分层生成不同环境的锁定文件，是最轻量、最可控、也最容易被 CI/CD 接入的方式。
为什么不能只靠一个 requirements.txt？
因为开发和生产环境的依赖天然不对等：开发需要 pytest、black、mypy，但这些不该进生产镜像；生产要严格锁定 gunicorn==21.2.0，但开发可能只想写 gunicorn>=21.0 留点弹性。
用 pip freeze > requirements.txt 会把所有包（包括 dev 工具）一股脑导出，既污染生产环境，又让版本不可控。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 部署时
pip install -r requirements.txt装了ipython进容器，白占 80MB 空间 -
pip list --format=freeze导出的版本含间接依赖（比如urllib3），但你根本没在requirements.in里声明它 —— 下次手动升级requests后，urllib3可能意外跳版，引发兼容问题
怎么用 pip-tools 实现分级依赖？
核心是把“声明”和“锁定”分离：requirements.in 写人看的逻辑依赖，pip-compile 自动生成机器执行的精确锁定文件。
操作步骤：
- 创建
requirements.in，只放生产必需的包（如django、psycopg2-binary） - 创建
requirements-dev.in，用-r requirements.in引入生产依赖，再追加开发工具：-r requirements.in pytest==7.4.4 black==24.3.0 mypy==1.10.0
- 分别编译：
pip-compile requirements.in→ 生成requirements.txt；pip-compile requirements-dev.in→ 生成requirements-dev.txt - CI/CD 部署阶段只运行
pip-sync requirements.txt，开发本地用pip-sync requirements-dev.txt
pip-sync 和 pip install -r 的关键区别
pip-sync 不是简单安装，而是「确保当前环境和锁定文件完全一致」：多装的包会被卸载，版本不符的会被重装，连注释里的 # via 信息都参与校验。
这能避免“上次手动 pip install foo 没写进文件，下次重装就漏了”的问题。
注意点：
-
pip-sync会删包，别在全局环境跑它 - 必须搭配
pip-compile生成的.txt文件使用，不能拿手写的requirements.txt直接 sync - 如果想保留某些包不被 sync 影响（比如系统预装的
setuptools），加--skip-requirements-regex "^(setuptools|wheel)$"
uv 可以替代 pip-tools 吗？
可以，而且更快。uv 的 uv pip compile 和 uv pip sync 命令行为几乎和 pip-tools 一一对应，语法也兼容 .in 文件。
但要注意两点：
- uv 默认启用
--no-deps类似行为，若你的requirements.in里有带[extra]的包（如requests[security]），得显式加--extra-index-url或用--find-links - 目前 uv 对
pyproject.toml中[project.optional-dependencies]的支持不如 Poetry 成熟，如果项目已用 Poetry 管理可选依赖，强行切 uv 可能导致dev组丢失
真正容易被忽略的是：无论用 pip-tools 还是 uv，requirements.in 文件本身必须进 Git，且每次改依赖都要重新 pip-compile 并提交锁定文件 —— 否则“分级”就退化成口头约定。
