怎样在Python中管理区分开发环境与生产环境专属依赖-Python教程-PHP中文网

最稳直接结论是用pip-tools分层编译：共用依赖写requirements.in，开发依赖写requirements-dev.in（以-r requirements.in开头），生产依赖写requirements-prod.in（仅-r requirements.in），再分别pip-compile生成锁定文件，确保环境隔离与部署确定性。

怎样在python中管理区分开发环境与生产环境专属依赖

用 requirements.in + pip-compile 区分环境依赖最稳

直接结论：别在 requirements.txt 里硬编码两套依赖，也别靠 if os.getenv("ENV") == "prod" 动态 import——这会让 pip 安装失败、CI 缓存失效、IDE 无法识别类型提示。真正可维护的做法是用 pip-tools 的分层编译机制。

核心思路是把共用依赖写进 requirements.in，开发专用依赖（如 pytest、mypy、ipdb）单独放进 requirements-dev.in，生产依赖（极少额外加，但可显式声明）放 requirements-prod.in。然后用 pip-compile 分别生成锁定文件：

pip-compile requirements.in --output-file=requirements.txt  
pip-compile requirements-dev.in --output-file=requirements-dev.txt  
pip-compile requirements-prod.in --output-file=requirements-prod.txt

requirements-dev.in 通常以 -r requirements.in 开头，再追加开发工具
requirements-prod.in 只需包含 -r requirements.in，不加任何 dev-only 包，避免污染线上环境
CI 部署时只 pip install -r requirements-prod.txt；本地开发用 pip install -r requirements-dev.txt
每次改了 .in 文件，必须重新 pip-compile，否则锁定文件过期，版本漂移风险极高

setup.py 或 pyproject.toml 中的 extras_require 是运行时区分关键

当你的包要被其他项目安装（比如发布到 PyPI），或需要支持 pip install mypkg[dev] 这种语法时，extras_require 是唯一正解。它不参与构建时安装，而是在用户明确指定 extra 时才拉取依赖。

在 pyproject.toml 中写法示例：

Python Code Tester

代码功能测试skill，根据用户需求搜索代码、生成测试用例、执行测试并修复问题

下载

[project.optional-dependencies]  
dev = ["pytest>=7.0", "mypy>=1.0", "black>=23.0"]  
test = ["pytest-cov", "responses"]  
prod = []  # 空列表也合法，显式声明语义清晰

安装开发依赖：pip install -e ".[dev,test]"（注意引号和点）
extras_require 不影响 pip install . 的默认行为，生产部署完全不受干扰
不能在 extras_require 里写条件逻辑（如 sys_platform == "win32"），pip 不解析运行时判断，只做静态匹配
如果用了 setuptools 的 setup.py，对应字段是 extras_require={...}，但推荐迁移到 pyproject.toml

环境变量 + requirements 文件名切换容易出错

有人喜欢用 pip install -r requirements-$ENV.txt，靠 shell 变量切换文件。问题在于：$ENV 在 Docker 构建阶段未定义、CI 脚本未 export、Windows CMD 不识别 $，都会导致安装空文件或报错 No such file。

不要依赖 shell 层动态拼接文件名——把决策逻辑交给工具（如 pip-compile）或配置（如 pyproject.toml）
若必须用环境变量控制，应统一在 Makefile 或 justfile 中定义规则，而不是裸写 pip install 命令
requirements-dev.txt 和 requirements-prod.txt 必须都提交进 Git，禁止忽略——它们是确定性部署的契约
检查 pip list 输出时，留意是否有 dev 相关包混入生产镜像，常见于 Dockerfile 写成 COPY requirements*.txt . 后全量安装

docker-compose.yml 或 Dockerfile 里漏掉 --no-deps 是隐形炸弹

Docker 构建时，如果用 pip install -e .[dev] 安装本地包，而没加 --no-deps，pip 会递归安装 setup.py 或 pyproject.toml 里声明的所有依赖（包括 dev），哪怕你本意只是装当前包用于调试。

生产 Dockerfile 应始终用 pip install --no-deps -e . + 单独 pip install -r requirements-prod.txt
开发用的 docker-compose.yml 可以挂载源码并 pip install -e ".[dev,test]"，但必须确认基础镜像已预装好 pip-tools 或 build-essential
Python 3.12+ 默认启用 install --break-system-packages 提示，若在容器内用 root 装包，记得加 --break-system-packages 显式确认（但更推荐用非 root 用户）