不能在 composer.json 里用变量控制租户依赖，因为 composer 解析时未启动 php 解释器，$_env、getenv() 和字符串拼接均不可用，require 值必须为静态字符串，动态写法如 "tenant-{$id}/module": "^1.0" 会直接报错。
为什么不能在 composer.json 里用变量控制租户依赖
因为 Composer 解析 composer.json 时根本没启动 PHP 解释器，$_ENV、getenv()、字符串拼接全不可用。所有 require 字段值必须是静态字符串，写 "tenant-{$id}/module": "^1.0" 会直接报 Invalid package name 错误。
常见翻车点包括：本地手动改 composer.json 切换租户 → CI 构建时因分支差异导致 composer.lock 不一致 → 部署后类加载失败；误以为 composer dump-autoload 能扫描运行时新增路径 → 它只读 autoload 块声明的路径，对 ClassLoader::addPsr4() 注册的路径完全无视。
租户级 vendor 隔离：什么时候该用独立 composer.json
适用于租户间依赖版本冲突严重（比如一个要 monolog/monolog:^2.0，另一个强制 ^3.0），且需强运行时隔离的场景。
- 动态生成的
composer.json中，仅允许动态字段：name（建议设为tenant/{id}）、require（必须校验白名单，禁用dev-master等危险版本）、autoload（如 PSR-4 映射到src/tenants/{id}/） - 禁止动态字段：
autoload-dev、scripts、config中的超时或插件配置——这些属于部署环境控制，不该由租户输入决定 - 安装命令必须加
--no-scripts -d "tenants/{$tenantId}"：避免触发全局钩子（如清缓存），并确保vendor写入租户专属目录 - 生成后需手动
include_once对应租户的vendor/autoload.php，且注意ClassLoader注册顺序——主项目加载器必须先于租户加载器注册，否则命名空间可能被覆盖
运行时 addPsr4()：轻量级插件热加载的核心路径
绕过 require，直接操作 Composer 自带的加载器实例，适合租户模块代码不进主 vendor、只需按需加载的场景。
关键约束：
- 租户模块目录结构必须严格符合 PSR-4，例如
modules/tenant-a/src/FeatureX/Handler.php对应命名空间AppTenantModulesAFeatureX - 调用
ClassLoader::addPsr4()必须在vendor/autoload.php加载之后，否则注册无效 - 若多个租户模块映射到同一命名空间前缀（如都用
AppPlugins），后注册的会覆盖先注册的——必须保证命名空间唯一性或按需清理旧注册 - 不支持自动发现新文件：修改模块代码后，需手动触发
ClassLoader::unregister()+ 重新addPsr4()，或重启进程
微服务边界下的 autoload 收敛与陷阱
PSR-4 映射不是越宽越好。微服务要求类加载路径与服务职责强绑定，否则自动加载器会“越界”加载其他服务代码，破坏隔离性。
典型错误配置：
-
"App\": "src/"→ 一旦某服务引入了其他服务的src/目录，就可能意外加载对方逻辑 - 跨服务共享包未收敛 autoload：比如
acme/shared-utils的src/同时被 A、B 两个服务映射到不同命名空间，会导致类名冲突或加载错乱 - 生产环境漏掉
--optimize-autoloader→ PSR-4 动态解析路径比classmap慢，高并发下可观测到毫秒级延迟上升
真正需要关注的不是“能不能加载”，而是“该不该加载”——autoload 配置本质是服务边界的声明，写宽了等于主动撕开隔离墙。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
