Composer本身不参与Jenkins负载调度，执行位置由agent标签匹配决定；需显式配置标签（如php82、composer2）、使用绝对路径调用（如/usr/local/bin/composer install），并为Composer任务分配专用Agent组以避免I/O与磁盘空间瓶颈。
Composer 本身不参与 Jenkins 的负载调度——调度完全由 Jenkins Master 决定，composer install 只是运行在某个 Agent 上的一个普通 shell 命令。真正决定“在哪台机器上执行 Composer”的，是 Jenkins 的 agent 配置和标签匹配逻辑。
agent 标签必须显式声明才能触发负载分发
如果你的 Pipeline 写的是 agent any，Jenkins 默认按轮询（Round Robin）选节点，但前提是所有可用 Agent 都没被限制使用。一旦某个 Agent 被手动下线、磁盘满、SSH 失联或未勾选“Use this node as much as possible”，它就会被跳过。
- 确保每个运行 Composer 的 Agent 都配置了明确标签，比如
php82、composer2、prod-build - 在 Pipeline 中用
agent { label 'php82 && composer2' }精确锁定，避免因标签缺失导致全部 fallback 到 Master（如果 Master 允许构建） - 不要依赖“自动识别 PHP 环境”——Jenkins 不会扫描 Agent 上的
composer --version，只认你填在节点配置里的Labels字段
composer install 的 I/O 和内存行为会放大 Agent 负载不均
Composer 安装过程大量读写 vendor/、解压 tarball、生成 autoloader，容易引发单节点磁盘 I/O 饱和或内存超限，进而让该 Agent 被 Jenkins 标记为“不健康”，退出调度池。
- 在 Agent 配置中启用“仅当节点空闲时才触发构建”，防止高负载下强行排队
- 为 Composer 任务单独分配 Agent 组，例如打标
composer-heavy，并限制该组最大并发数（通过 Node 的Number of executors控制，建议 ≤ CPU 核数） - 避免在共享工作目录（如
/var/lib/jenkins/workspace）跑多个 Composer 项目——推荐用Custom workspace指向大容量独立分区，路径如/data/composer-workspace
流水线里调用 composer 必须指定完整路径或环境
Jenkins 不继承 Agent 的 shell profile，composer 命令很可能找不到，尤其当它是通过 snap、curl -sS https://getcomposer.org/installer | php 或本地 bin 目录安装时。
- 统一用绝对路径调用：
sh '/usr/local/bin/composer install --no-dev' - 或在
tools块中声明全局 Composer 工具（需提前在 Jenkins 系统配置里注册），再用withEnv(['PATH+COMPOSER=/path/to/composer/bin'])注入 - 检查 Agent 启动方式：SSH 启动的 Agent 默认不加载
~/.bashrc，改用sh -l -c "composer --version"测试是否能正确加载环境
最常被忽略的一点：Composer 任务的“负载”不是 CPU 占用率，而是磁盘空间增长速度和临时文件锁竞争。一个 composer update 可能在 5 分钟内写入 2GB 临时文件，而 Jenkins 的健康检查默认只看 SSH 连通性和进程存活——等发现磁盘爆满时，已经有一批任务失败了。
