Composer 无定时调度能力，Laravel 通过系统 cron 触发 schedule:run 实现调度；负载响应需在命令 handle() 中用 sys_getloadavg() 判断，配合 Redis 计数与数据库配置实现集群降频，高负载时应延迟而非跳过任务。
Composer 本身不提供定时调度能力
很多人误以为 composer 能直接跑定时任务，其实它只是依赖管理工具，没有内置 cron 或 schedule 功能。所谓“Composer 定时调度”，实际是指用 Composer 管理的 PHP 项目（比如 Laravel）中，通过系统 cron 触发 php artisan schedule:run，再由框架调度具体命令。优化重点不在 Composer，而在调度逻辑本身是否感知负载。
如何在 Laravel 的 Artisan 命令中读取并响应系统负载
核心是把负载判断逻辑下沉到具体命令的 handle() 方法里，而不是塞进 schedule() 函数——后者只负责注册计划，无法动态调整。
- 用
sys_getloadavg()[0]获取 1 分钟平均负载值，轻量、无额外依赖 - 避免在
schedule()中写if (load > 1.5) return;—— 这会导致整个调度器跳过所有任务，不是“降频”，而是“停摆” - 推荐封装成可复用 trait，例如
LoadAware，在handle()开头调用$this->shouldSkipDueToLoad() - 注意：Docker 容器内读取的 load 是宿主机值，若需容器级负载，改用
/sys/fs/cgroup/cpu.stat解析usage_usec
数据库配置 + Redis 协同实现集群安全降频
单机负载判断在集群下会失效：三台机器同时看到 load=0.6，结果都执行了耗资源任务，总负载瞬间冲到 2.0。必须引入共享状态。
- 用 Redis 的
INCR+EXPIRE组合做轻量计数，例如INCR "sched:active:send-emails"，返回值 > 2 则主动退出 - 数据库表
scheduled_tasks至少存三个字段：command_name、current_interval、last_load_value，每次任务执行后更新 -
withoutOverlapping()和onOneServer()必须配合使用：前者防单机重叠，后者防集群重叠，缺一不可 - 别把负载阈值硬编码在代码里，从 DB 或 Redis 读取，方便运维热更新
为什么 load > 1.5 就该推迟到凌晨，而不是直接跳过
跳过是懒办法，容易累积延迟导致数据不一致；推迟才是工程解法——但推迟不能靠 sleep(3600)，那会卡住整个 worker 进程。
- 真正做法是：检测到高负载后，调用
Artisan::queue()把任务推入队列，并指定delay参数，例如->delay(now()->addHours(6)) - 确保队列驱动支持延迟（Redis/Database 都行，file 不行）
- 凌晨触发条件建议加双重保险：时间戳 + 当前负载
- 最容易被忽略的一点：所有推迟逻辑必须记录日志或埋点，否则你永远不知道某次关键任务到底被“推迟”还是“丢弃”了
