Composer不处理配置切换，多环境配置须由PHP运行时实现；autoload.files不解析变量，配置加载应放在入口文件或dotenv中；require-dev是安装范围开关而非环境开关；platform仅影响update阶段包选择；composer.lock是跨环境一致性的唯一依据。
Composer 本身不处理配置文件切换，它只管装包；所谓“多环境配置”，必须靠 PHP 运行时逻辑来实现，不是靠 composer.json 或 autoload.files 动态加载。
别在 autoload.files 里写带变量的路径
常见错误现象：autoload.files 中写了 "config/{$_ENV['APP_ENV']}.php"，结果 composer dump-autoload 直接报错或加载失败——因为 Composer 解析 composer.json 是纯 JSON，不执行 PHP，更不解析变量。
实操建议：
- 所有配置加载逻辑必须放在 PHP 入口文件（如
public/index.php）或引导脚本中 - 用
getenv('APP_ENV')或$_SERVER['APP_ENV']获取环境标识，再拼路径require __DIR__ . '/../config/' . $env . '/app.php' - 若用
vlucas/phpdotenv，必须先调用Dotenv\Dotenv::createImmutable()加载对应.env.{env}文件，再读取APP_ENV
require-dev 不是“环境开关”，而是“安装范围开关”
很多人以为把某个类放进 autoload-dev 就等于“只在开发环境可用”，这是误解。它只控制 vendor/autoload.php 是否注册该命名空间，不控制运行时行为。
实操建议：
- 生产部署必须加
composer install --no-dev --optimize-autoloader，否则phpunit、symfony/var-dumper等包会进vendor/，且其autoload-dev映射不会被写入自动加载器 - 如果某配置类（如
ProdDatabaseConfig）被生产代码 new 出来，它就必须在autoload下，不能塞进autoload-dev - 检查隐式依赖：运行
composer depends symfony/var-dumper --tree，确认没有生产代码路径依赖 dev-only 包
config.platform 不影响运行时，只影响 update 阶段的包选择
典型误用：在 composer.json 里写 "platform": {"php": "8.1.0"}，就以为能“让项目在 PHP 8.1 下运行”，结果上线后因缺 ext-gd 报错——platform 压根不装扩展，也不改当前 PHP 版本。
实操建议：
-
platform只用于composer update时模拟目标环境，避免选到不兼容的包版本 - 真实 PHP 版本由系统
php命令决定；多版本共存时，用COMPOSER_PHP=/usr/bin/php8.1显式指定解释器 - CI 构建中可加
COMPOSER_PLATFORM_CHECK=0关闭校验，但前提是已确保平台一致性
composer.lock 是多环境一致性的唯一依据
删 vendor 目录、换 composer.json 内容、甚至重跑 composer install，都不如一个提交到 Git 的 composer.lock 可靠。它锁死每个包的确切版本和哈希，跨环境还原才真正一致。
容易被忽略的点：
-
composer.lock必须提交 Git，不能忽略；它不是“缓存”，是契约 - 不同环境执行
composer install时，只要 lock 文件一致，且没加--no-dev差异，结果就完全相同 - 别搞
composer.prod.json+ 脚本替换这种方案——它绕过 lock 文件，破坏可重现性，且难以审计
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
