Composer本身不支持带宽分配，多租户场景下需在反向代理、私有仓库后端或CI/CD层实现限速，或通过统一缓存目录与预热提升复用率来降低实际带宽消耗。

多租户场景下 Composer 本身不支持带宽分配

Composer 没有内置的「按租户/项目限速」能力，composer install 或 composer update 过程中所有 HTTP 请求都走 PHP 的 cURL 或 Stream 封装器，底层不感知租户上下文，更不会读取 tenant_id 或项目配置来动态限流。试图在 composer.json 里加 "bandwidth_limit": "100k" 这类字段会直接报错 —— 它根本不是合法 schema 字段。

真正能控制带宽的地方只有网络层或代理层

想对不同租户的依赖下载做带宽隔离，必须把控制点前移到 Composer 发起请求之前的位置：

• 在反向代理（如 Nginx）或网关层，根据请求 URL 中的租户标识（例如 https://pkgs.example.com/tenant-a/）匹配 location 块，用 limit_rate 限制响应带宽
• 若使用 Private Packagist 或自建 Satis，可在其后端服务（如 Laravel 应用）中对 /packages/tenant-{id}.json 接口做中间件限速，用 RateLimiter::attempt() + response()->stream() 控制输出速率
• CI/CD 流水线中，对每个租户构建作业单独设置系统级限速：比如用 trickle -s -u 512 composer install（单位 KB/s），但注意 trickle 不兼容某些容器运行时

别指望 --prefer-dist 或 --no-plugins 能降低带宽 —— 它们只影响是否解压、是否执行脚本，不改变下载体积。

缓存才是更实际的“带宽节省”手段

与其硬限速导致安装超时失败，不如让多数请求命中本地缓存：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 所有租户共享同一 ~/.composer/cache 目录（默认行为），只要一个租户下载过 monolog/monolog:3.0.0，其他租户再装就跳过下载
• 确保 cache-dir 配置统一且可写：composer config -g cache-dir "/shared/composer-cache"
• 私有仓库返回的 dist.zip URL 必须带校验参数（如 ?v=sha256:abc123），否则 Composer 无法复用缓存（HTTP 缓存 key 不一致）
• 边缘节点部署时，可提前用 composer download --prefer-dist 预热缓存，避免上线时集中拉取

缓存复用率每提升 10%，实际带宽消耗下降远不止 10% —— 因为 zip 包通常比 metadata 大 1–2 个数量级。

租户级安装命令必须显式隔离工作目录

即使做了带宽控制，如果多个租户共用同一 composer install 进程，仍可能因并发争抢磁盘 I/O 或临时文件冲突导致失败：

• 每个租户安装必须指定独立目录：composer install --no-scripts --no-interaction -d "tenants/abc123"
• 禁止在项目根目录运行租户命令，否则 vendor/ 和 composer.lock 会被覆盖
• -d 参数必须绝对路径，相对路径在 CI 环境中容易因 cd 切换失效
• 若用 Docker，为每个租户分配独立 volume，避免宿主机缓存目录被并发写坏

带宽策略再细，也救不了路径混用 —— 这是多租户 Composer 最容易被忽略的执行边界。