Composer本身不支持多节点调度与负载分流，因其本质是单机PHP包管理器，仅负责本地依赖解析、下载、写入vendor及生成自动加载文件，不启动服务、不监听端口、不维护节点列表，所有操作无状态且顺序执行。
Composer 本身不支持多节点调度与负载分流——它是个 PHP 包管理器，不是分布式任务调度系统，也不参与运行时流量分发。
为什么 composer install 不会“调度到多个节点”
Composer 的核心职责是解析依赖、下载 ZIP/tar 包、写入 vendor/、生成自动加载文件。整个过程是单机、顺序、无状态的：
- 所有操作在本地执行，不启动服务，不监听端口，不维护节点列表
-
composer update期间可能并发下载多个包，但这是 HTTP 客户端级别的并行（类似curl多线程），不是节点级调度 - 所谓“镜像源”只是替换
packagist.org的 HTTP URL，不涉及节点发现、健康检查或权重分配
容易混淆的三个概念：Composer vs Composer（MosaicML） vs 负载均衡中间件
名字撞车导致大量误查：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer（PHP 包管理器）：命令行工具，配置在composer.json，行为由composer.lock锁定 -
composer（MosaicML 深度学习库）：Python 库，含Trainer类，支持 DDP/FSDP 多 GPU/多节点训练，但和 PHP 无关 - 负载分流：需 Nginx、HAProxy、Traefik 或服务网格（如 Istio）实现，Docker Compose 中靠
deploy.replicas+ 反向代理达成
真要实现“PHP 应用多节点+分流”，该配什么
如果你实际想部署的是 PHP Web 服务（比如 Laravel、Symfony），那调度和分流发生在运行时，和 Composer 无关：
- 用
docker-compose.yml启动多个php-fpm实例，设replicas: 3 - 前端加 Nginx，
upstream指向服务名（如php:9000），Docker DNS 自动做轮询 - 关键路径必须无状态：session 存 Redis，文件上传走对象存储，数据库连接池独立
- Composer 只在构建阶段运行（
Dockerfile里RUN composer install --no-dev），完成后镜像就固定了
真正容易被忽略的是：很多人把 composer install 放进容器启动脚本里，每次起容器都重装依赖——这既拖慢扩容速度，又因网络波动导致启动失败。正确做法是把依赖固化进镜像层，而非运行时动态拉取。
