Composer 本身不参与负载调度，它仅在构建阶段安装 PHP 类库；Kubernetes 等调度器只依据 Pod 的 resources、affinity 等字段决策，完全不解析 composer.json 或 composer.lock。
Composer 本身不参与负载调度——它不是运行时服务，也没有调度器、节点发现或流量分发能力。所谓“平台依赖参与负载调度”，本质是混淆了 composer.json 中声明的依赖与实际运行环境（如 Kubernetes、Docker Swarm 或云函数）的调度机制。
为什么 composer require 的包不会影响 Pod 调度
你在 composer.json 里写 "guzzlehttp/guzzle": "^7.5"，只决定构建阶段装什么 PHP 类库；Kubernetes 调度器看的是 Pod 的 resources、nodeSelector、affinity 等字段，完全不解析 PHP 代码或 composer.lock。即使你装了 100 个 HTTP 客户端，也不会让调度器多分配一个 CPU 核心。
- 调度决策发生在容器启动前，依赖安装发生在镜像构建期（或 initContainer 阶段）
- Composer 安装的只是 PHP 文件，不注册监听端口、不暴露服务、不上报健康状态
- 真正影响调度的，是运行时行为：比如某个包触发了大量内存分配，导致 OOMKilled，进而触发重启和重调度——但这属于间接副作用，不是 Composer 的调度参与
哪些“依赖”可能被误认为参与调度
容易被混淆的其实是 带运行时 sidecar 或 CLI 工具的包，例如：
-
spatie/laravel-backup：它本身不调度，但若你用 Laravel Schedule + cron 在容器里跑备份任务，就可能因资源争抢影响 Pod 稳定性 -
php-enqueue/enqueue或symfony/messenger：它们封装了消息消费逻辑，但消费器是否水平伸缩，取决于你如何部署 worker 进程（比如用 StatefulSet 控制副本数），而非包本身 -
ext-redis或ext-pdo_pgsql：C 扩展不参与调度，但若配置错误（如连接池耗尽、SSL 路径不对），会导致应用崩溃，触发 Kubernetes 的 liveness probe 失败和自动重建
真正在调度链路中起作用的 Composer 相关环节
唯一和调度有弱耦合的，是 构建产物对镜像体积和启动时间的影响：
- vendor 目录过大 → 镜像拉取慢 → Pod Pending 时间变长 → 影响调度吞吐量
- autoload 未优化（没加
--optimize-autoloader）→ PHP 启动时遍历目录耗时 → readiness probe 延迟通过 → 流量接入晚 - require-dev 包混入生产镜像（比如漏加
--no-dev）→ 增加攻击面和内存 footprint → 可能触发 HorizontalPodAutoscaler 提前扩容
归根结底，Composer 管理的是“装什么”，不是“怎么跑”。调度系统只认容器镜像、资源配置和探针行为。把依赖管理当成调度策略来设计，等于在 makefile 里写 kubectl 命令——看起来有关联，实则职责错位。
