Composer不支持if-else环境分支，因其仅静态解析JSON，不执行逻辑判断；多环境需靠动态注入repositories、环境感知脚本或外部配置+自定义installer实现。
Composer 本身不支持多环境配置（如 dev/staging/prod）的原生切换机制，所谓“多环境配置”实际是靠项目级 repositories + 条件化脚本 + 外部变量协同实现的。
为什么 composer.json 不能直接写 if-else 环境分支
Composer 解析 composer.json 时只做静态 JSON 读取，不执行 PHP 或环境判断逻辑。任何试图用 "require": { "dev-only/package": {"dev": "^1.0"} } 这类写法都会导致解析失败或被忽略。
常见错误现象包括：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 运行
composer install报错JSON decode error，实际是字段结构非法 - 本地
composer install成功，CI 上却拉不到私有包——因为 CI 环境没注入对应仓库配置 - 误以为
require-dev是“仅开发环境生效”，其实它只是控制是否在--no-dev模式下安装，repositories仍全程参与依赖解析
真正可用的三类多环境配置落地方式
小团队实践中能稳定生效的只有以下三种组合，且必须配合显式清理与 lock 文件重生成：
-
项目级 repositories 动态注入：在 CI/CD 脚本中，根据环境变量决定是否执行
composer config repo.my-private composer https://private.repo.example.com/，再删vendor/和composer.lock后跑composer install -
环境感知的脚本钩子：在
composer.json的scripts中用 shell 判断$ENV，例如："post-install-cmd": ["[ \"$ENV\" = \"prod\" ] && rm -f .env.local"] -
外部配置文件 + 自定义 installer：把仓库 URL 提炼成
.env.composer，通过自定义 Composer 插件在pre-install-cmd阶段读取并调用Composer\IO\IOInterface::write()注入临时仓库（需额外开发，适合中大型团队）
最容易被忽略的兼容性陷阱
Composer 2.x 默认启用 canonical 行为，即一旦某个仓库声明了某包，后续仓库同名包将完全不可见。这意味着：
- 若 staging 环境需要从私有源装
acme/core，而 prod 又需从另一个私有源装同名包，两个仓库必须都设"canonical": false，否则后声明的会被跳过 -
only和exclude过滤规则只在 canonical 模式下生效；非 canonical 时所有仓库全量合并，可能引发版本冲突 - 本地开发用
composer update时，若未加--with-dependencies，可能漏掉被only规则隐式排除的间接依赖
真正起效的从来不是“配置多套”，而是确保每次 composer install 前，composer.json 的 repositories 数组只包含当前环境真正需要的源，并且 composer.lock 是由该配置首次生成的。
