composer不支持按环境动态加载依赖，其composer.json为静态配置，需通过--no-dev控制require-dev安装、config.platform模拟环境约束、运行时判断等方式间接实现。
Composer 本身不支持按环境动态加载不同依赖，composer.json 是静态配置文件，没有 if env === "prod" 这类逻辑。所谓“灵活切换”，本质是靠人为分层 + 显式控制安装行为来实现，不是靠 Composer 自动识别环境。
用 --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 版本，也不解决运行时扩展缺失问题。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 真实没装
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 和环境变量看似相关，实则各管一段——一个只管依赖解析，一个只管命令执行器，两者不互通。把逻辑混在这两层之间，迟早出事。
