Composer 不支持环境动态切换 require 或 autoload 配置，因其解析器不执行 PHP 代码，所有字段仅接受字符串字面量；真正可行的是三步法：移出环境专属模块、运行时 addPsr4 动态注册、严格管控 ClassLoader 实例生命周期。
先明确一个核心事实：Composer 本身并不具备按环境动态切换 require 或 autoload 配置的能力。无论是依赖声明还是自动加载规则，在 composer.json 里都是静态的，一旦执行安装或更新，这些规则就被固化了。所以，我们常说的“环境区分加载”，本质上是一套组合策略：用 composer install --no-dev 来控制依赖范围，再配合运行时的条件判断和 PSR-4 动态注册，才能真正实现不同租户或环境之间的隔离。
为什么不能在 composer.json 里写 if-env 逻辑？
原因很简单：Composer 的依赖解析器并不执行 PHP 代码。这意味着，require、autoload.psr-4 这些字段，只能接受字符串字面量，任何动态逻辑在这里都行不通。开发者常踩的几个坑包括：
- 试图在开发分支写
"App\TenantA\": "modules/tenant-a/src/"，上线后又想切换成"App\TenantB\": "modules/tenant-b/src/"。这会导致composer install失败，或者类加载直接错乱，因为vendor/autoload.php已经按照旧的配置生成了。 - 在
autoload.files中引用那些包含$_ENV或getenv()的文件。这些环境变量在dump-autoload阶段根本不可用，文件自然不会被收录进autoload_files.php。 - 误以为
config.platform能控制自动加载路径。其实它只影响依赖版本的解析，对命名空间映射规则毫无作用。
真正可行的环境区分加载三步法
核心思路不是让 Composer 去“理解”环境，而是让它生成一个通用的基础加载器，然后由应用层来补充差异化的部分。具体怎么做？分三步走：
- 第一步，基础依赖走
require，环境专属模块全部移出composer.json：比如，像tenant-a-feature-x这样的模块，就不要出现在任何require字段里，避免被 Composer 解析和安装。 - 第二步，模块目录物理存在，但仅靠运行时
$loader->addPsr4()动态注册：以 Lara vel 框架为例，可以在服务提供者里这样写：$loader = require __DIR__.'/../vendor/autoload.php'; if (config('tenant.id') === 'a') { $loader->addPsr4('App\TenantA\', base_path('modules/tenant-a/src/')); } - 第三步，必须检查是否已注册，避免重复污染
getPrefixesPsr4()：重复调用addPsr4()会导致同一个命名空间映射到多个路径，类加载行为将变得不可预测。
容易被忽略的生命周期陷阱
动态注册的效果只对当前的 ClassLoader 实例生效。而这个实例，通常在请求开始时创建（比如在 Lara vel 的 app()->booted() 阶段），并且不会跨进程持久化。这里有三个常见的陷阱：
- PHP-FPM 子进程启动后，
autoload.php只加载一次。之后如果新增了模块目录，不重启 FPM 或重载容器，旧的进程永远也找不到新的类。这可不是缓存问题，而是因为ClassLoader实例没有重建。 - 在 Docker 环境下，即使挂载了
modules/目录，如果没有触发opcache_reset()或 FPM reload，class_exists()依然会返回false。 - CLI 命令（比如 Artisan）和 Web 请求的生命周期是不同的。必须确保两者都执行了相同的注册逻辑，否则就会出现“Web 端能加载，命令行却报 Class not found”的诡异情况。
说到底，最关键的不是怎么写配置，而是要搞清楚：谁，在什么时候，持有着哪个 ClassLoader 实例。几乎所有“明明文件存在、也调用了 addPsr4 却找不到类”的问题，根源都卡在这里。
