Composer 本身不提供边缘调度能力，它仅负责PHP依赖安装，不参与运行时资源分配；真正的边缘负载均衡由底层调度器（如K8s kube-scheduler）、边缘Agent或网关（如ESA）承担。
直接说结论：Composer 本身不提供边缘调度能力，所谓“Composer 边缘调度负载不均”，本质是误用了 Composer 的定位——它只管 PHP 依赖安装，不参与运行时资源分配。真正在边缘侧做负载均衡的，是底层调度器（如 K8s kube-scheduler、自研 Agent 调度模块）或边缘网关（如 ESA 负载均衡器），Composer 只在容器构建阶段起作用。
为什么 Composer 被扯进边缘调度问题？
常见误解场景有两类： - 误把composer install 执行慢当成“调度卡顿”：实则是某边缘节点磁盘 I/O 差或网络拉包慢，和调度算法无关
- 在 CI/CD 流水线里用 Composer 构建多版本镜像，但部署时没做节点亲和性约束，导致高配节点没分到任务，低配节点堆满 PHP-FPM 实例
边缘节点负载不均，该调谁？
CPUUsage、不上报 ResourceReport、不参与 maybeBalance() 判断。真正要调的是：
- 边缘 Agent 的资源上报频率与指标维度（例如是否漏报 GPU 显存或网络丢包率）
- 调度器使用的策略类型（LeastConnections 对 PHP 长连接有效，WeightedRoundRobin 需对齐实际 CPU 核数权重）
- 负载均衡器健康检查配置（HTTP 探针若只查 /health 而不校验 PHP-FPM 子进程数，会误判节点“健康”）
PHP 应用在边缘跑不均？先看这三处硬伤
-opcache.memory_consumption 在不同边缘节点未统一：小内存节点开大缓存会频繁 OOM，触发容器重启，被调度器反复剔除又加回
- pm.max_children 硬编码为 50：高配节点只用 30%，低配节点早被压垮，应改用动态计算（如 memory_limit / 20MB）
- Composer 自动加载的 vendor/autoload.php 被 APCu 缓存，但边缘节点间未共享缓存键：同一类请求在 A 节点命中，在 B 节点全量重解析，造成 CPU 使用率毛刺式抖动
真正有效的调优动作清单
- 检查边缘 Agent 上报的ResourceReport 是否包含 MemoryFree 和 CpuUsage 字段，缺失则调度器只能按静态权重分发
- 把负载均衡器的探测协议从 ICMP Ping 改为 HTTP，并指向真实 PHP 健康端点（如 /status?full），该端点需返回当前 pm.status 中的 active processes 数
- 若用 ESA 负载均衡器，确认源地址池中各节点的 权重 值与实测 PHP 吞吐量（req/s）匹配，而非简单按 CPU 核数设为 4/8/16
- 在 PHP 容器启动脚本里加一行：echo "$(($(cat /sys/fs/cgroup/memory/memory.limit_in_bytes) / 1024 / 1024))" > /tmp/memory_mb，供调度器读取真实内存上限
边缘调度的复杂点不在代码多难写，而在于 PHP 进程模型（prefork）和边缘资源波动（如 4G RAM 节点突然被邻居容器吃掉 1.5G）之间存在隐式耦合——这点连很多 ResourceReporter 结构体都没预留字段去刻画。
