Composer不支持环境判断，多环境差异需靠--no-dev、config.platform和运行时变量协同实现，禁止用多composer.json或autoload动态加载，必须提交composer.lock保障一致性。
Composer 本身不支持环境判断，composer.json 是静态配置文件，无法写 if env === 'prod' 这类逻辑。多环境差异必须靠外部控制 + 运行时配合，否则容易导致本地能跑、线上报错、composer.lock 冲突、依赖不一致等实际故障。
用 --no-dev 控制开发依赖是否安装
这是最常用也最容易漏掉的关键操作。生产部署时若没加 --no-dev，phpunit、laravel-debugbar、symfony/var-dumper 等包会进线上环境，带来安全风险和性能损耗。
-
composer install --no-dev：跳过require-dev中所有包的安装，但保留autoload-dev的定义（只是不装，不是禁用） - CI/CD 脚本、Dockerfile 中必须显式加上，不能依赖默认行为
-
--no-dev优先级高于COMPOSER_DEV_MODE=1，但变量更适合在容器启动前统一设置 - 如果
require-dev里有运行时需要的工具（比如调试用的symfony/var-dumper），别盲目关掉——它不是“只给测试用”的保险丝
用 config.platform 模拟目标环境的 PHP 和扩展
本地是 PHP 8.2，线上是 PHP 8.1？本地装了 ext-xdebug，线上没有？Composer 会因平台不匹配拒绝安装某些包，或在运行时报 Call to undefined function。用 config.platform 可以让 Composer “假装”环境已就绪。
- 在
composer.json中写死平台版本："config": { "platform": { "php": "8.1.0", "ext-gd": "8.1.0" } } - 版本号必须是具体值，不能用
^8.1或~8.1，否则无效 - 它只影响依赖解析阶段，不解决运行时缺失扩展的问题——真实没装
ext-gd，代码调用imagecreate()仍会崩 - 上线时可加
COMPOSER_PLATFORM_CHECK=0关闭校验，比改platform更干净，尤其适合 CI 构建
环境相关逻辑必须挪到 PHP 运行时
Composer 只负责装包，不负责行为分支。数据库配置、日志级别、缓存驱动这些，得靠 PHP 代码读取环境变量决定，而不是指望 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.prod.json 这类多配置文件
有人想通过替换 composer.json 文件来区分环境，这是反模式。Composer 不支持多配置切换，强行分裂会导致 composer.lock 哈希不一致、本地和线上依赖树不同、CI 构建不可重现。
-
composer install -c composer-prod.json看似可行，实则破坏 lock 文件与 json 的绑定关系 - 不同环境共用同一份
composer.json和composer.lock，靠--no-dev、config.platform、运行时变量来适配 - 如果真要彻底隔离依赖集（比如 prod 用 A 包、dev 用 B 包且互斥），唯一可靠方式是拆成独立包 +
path类型仓库，但代价高，99% 的项目不需要
真正容易被忽略的是：环境变量（如 APP_ENV）和 Composer 行为（如是否装 require-dev）是两套独立系统，不能混用。一个控制运行时逻辑，一个控制依赖安装，必须各司其职，否则就会出现「调试工具没装上却还在代码里 new TestClass()」或者「生产环境加载了开发用的 .env 文件」这类问题。
