如何通过Composer实现灵活调整开发与生产环境依赖？

本文共计1065个文字，预计阅读时间需要5分钟。

`Composer` 本身不支持按环境动态加载不同的依赖。`composer.json` 是一个静态配置文件，用于定义项目依赖。它不包含环境相关的条件语句，如 `if (env==dev)`。因此，您不能直接在 `composer.json` 中使用环境变量来指定不同的依赖。

用 --no-dev 精确控制开发依赖是否安装

这是最常用、也最容易被跳过的操作。生产部署时若漏掉 --no-dev，phpunit、laravel-debugbar、symfony/var-dumper 这些包会进线上环境，带来安全风险和性能损耗。

• composer install --no-dev 不仅跳过 require-dev 中的包安装，还会从自动加载中排除它们——vendor/autoload.php 不包含 autoload-dev 定义的类路径
• CI/CD 脚本、Dockerfile 中必须显式写上，不能依赖默认行为；--no-dev 优先级高于 COMPOSER_DEV_MODE=1
• 如果某个包既用于开发又需在生产运行（比如 barryvdh/laravel-debugbar 的部分功能），就不能放进 require-dev，得改用运行时判断或插件机制

别碰 config.platform 来“假装”环境

config.platform 只影响 composer update 阶段的依赖解析，比如你本地是 PHP 8.3、生产是 PHP 8.1，设 "platform": {"php": "8.1.0"} 可让 Composer 按 8.1 选包；但它完全不改变实际执行 composer install 的 PHP 版本，也不解决运行时扩展缺失问题。

• 真实没装 ext-gd，代码调用 imagecreate() 仍会报错，platform 压根救不了
• 版本号必须写死，如 "8.1.0"，不能用 ^8.1 或 ~8.1，否则无效
• 上线构建时，更干净的做法是加 COMPOSER_PLATFORM_CHECK=0 关闭校验，尤其适合 CI

环境差异必须下沉到 PHP 运行时

数据库配置、缓存驱动、日志级别这些，得靠 PHP 代码读取环境变量决定，而不是指望 Composer 加载哪个文件。Composer 只负责装包，不负责行为分支。

• 别在 autoload.files 里写 "config/{$_ENV['APP_ENV']}.php"——Composer 不解析 PHP 变量，会直接报错
• 统一用 vlucas/phpdotenv 加载 .env，再在应用代码中用 getenv('APP_ENV') 判断
• 框架如 Laravel/Symfony 已内置该机制；自己搭脚手架时也要遵循：先加载通用 .env，再按 APP_ENV 值选配置目录或键名
• composer.lock 必须提交 Git，它是多环境一致性的唯一保障；删 vendor 并不能“隔离环境”，反而破坏可重现性

彻底放弃多 composer.json 文件的念头

有人搞 composer.prod.json、composer.dev.json，再配合脚本替换，这属于反模式。它会导致 composer.lock 冲突、依赖树不一致、CI 构建失败等实际故障。

• composer install 读 composer.lock 复现已知依赖树；composer update 忽略 lock 文件重算依赖，易致环境不一致
• 团队协作、上线部署、CI/CD 流水线：必须用 composer install，确保所有人用同一套包版本
• 没有 composer.lock？说明项目没走规范流程，install 会退化成 update 行为，风险极高

真正容易被忽略的点是：--no-dev 不只是“少装几个包”，它直接决定了哪些类能被自动加载；而 config.platform 和环境变量看似相关，实则各管一段——一个只管依赖解析，一个只管命令执行器，两者不互通。把逻辑混在这两层之间，迟早出事。