通过 config.platform 锁定目标环境 PHP/扩展版本、require-dev 隔离开发测试依赖、--no-dev 控制生产安装，并提交 composer.lock，可确保三套环境依赖一致且干净分离。
用 composer.json 的 config.platform 和环境感知的脚本配合 require-dev，再辅以不同环境的部署流程控制，就能干净地区分三套依赖配置。
用 require-dev 隔离开发与测试专用包
所有仅在开发、测试阶段需要的工具（如 PHPUnit、PHPStan、Mockery、infection）统一放在 require-dev 里。生产环境部署时加 --no-dev 参数，Composer 就不会安装它们，也不会写入 autoload-dev 规则。
- 本地开发和 CI 测试环境运行
composer install（默认含 dev 包） - 生产服务器部署执行
composer install --no-dev --optimize-autoloader - 确保
composer.lock提交到版本库，让各环境依赖版本完全一致
用 config.platform 锁定目标环境 PHP 和扩展能力
开发机可能装了最新 PHP 和一堆扩展，但生产环境受限（比如只支持 PHP 8.1、没安装 ext-redis）。直接在 composer.json 中设置 config.platform，能强制 Composer 按目标环境能力解析依赖，避免“本地能装，线上装不上”的问题。
- 例如生产跑 PHP 8.1 + MySQL + no Redis：添加如下配置
"config": {
"platform": {
"php": "8.1.27",
"ext-mysqlnd": "8.1.27",
"ext-pdo_mysql": "8.1.27"
}
}
- 这样即使本地有
ext-redis，Composer 也不会选依赖它的包版本（除非你明确 require） -
platform不影响运行时，只影响安装时的依赖解析逻辑
按需加载环境专属配置（不靠 Composer 自动处理）
Composer 本身不支持“按环境自动切换 require 列表”，所以不要试图用脚本动态改 composer.json。真正需要差异化依赖时（比如测试用 SQLite 驱动、生产用 PostgreSQL 驱动），应把驱动抽象成接口，用 DI 容器或配置文件在运行时决定实例化哪个类——依赖包本身仍统一 require 在 require 或 require-dev 中。
- 例如同时 require
doctrine/dbal和sqlite3（dev）、pdo_pgsql（prod），但实际连接逻辑由DB_DRIVER环境变量控制 - 避免为不同环境维护多份
composer.json，那会破坏锁文件一致性，也增加出错概率
CI/CD 中显式控制安装行为
在 GitHub Actions、GitLab CI 或部署脚本中，用明确命令区分环境行为：
- 开发环境 CI（如 PR 检查）：运行
composer install && vendor/bin/phpunit - 测试环境（staging）：可加
--no-interaction --no-progress，但保留--dev - 生产部署：固定使用
composer install --no-dev --no-interaction --optimize-autoloader --apcu-autoloader - 所有步骤都基于同一份
composer.lock，确保“所测即所发”
基本上就这些。不复杂但容易忽略的是：平台锁定和锁文件提交这两步——它们才是跨环境依赖一致性的真正基石。
