不能用 sleep() 实现定时任务间隔，因为 cron 只负责按时启动进程，不控制其内部执行；sleep() 仅挂起当前进程，导致多进程堆积、资源占用升高。应通过 cron 表达式配置真实间隔，如 /5 * 表示每 5 分钟执行一次。
PHP 定时任务里不能靠 sleep() 来“延时控制执行间隔”，在 cron 中调用 sleep() 不但无效，还会导致任务堆积、资源占用升高，甚至掩盖真实调度问题。
为什么 cron + sleep 不能替代定时间隔
cron 只负责“在指定时间点启动进程”，它不管理进程内部行为。一旦 PHP 脚本被 cron 启动，sleep() 只会让当前进程挂起，但 cron 不会因此推迟下一次触发——它仍按原计划（比如每分钟）拉起新进程。
- 结果是：多个
sleep中的 PHP 进程并行堆积，内存/CPU 持续上涨 -
sleep(300)并不等于“每 5 分钟执行一次”，而是“每次启动后等 5 分钟再干活”，但 cron 还是每分钟都再启一个 - 脚本异常退出时，
sleep中断不可控，无法保证下次执行时机
真正可控的间隔方案：改 cron 表达式
想实现“每 N 分钟执行一次”，唯一可靠方式是配置 cron 本身，而不是在 PHP 里加 sleep()。
- 每 5 分钟：
*/5 * * * * - 每 10 分钟，且只在工作日：
*/10 * * * 1-5 - 每小时第 12 分钟：
12 * * * * - 避免秒级精度需求——cron 最小粒度是 1 分钟；需要秒级请用
systemd timer或外部守护进程
PHP 内部需要延时？只用于非调度逻辑
如果 PHP 脚本内确实要暂停（比如请求第三方 API 前等待、重试退避、模拟节流），sleep() 或 usleep() 是可用的，但必须明确：这不是调度手段，只是业务逻辑的一部分。
立即学习“PHP免费学习笔记（深入）”；
-
sleep(2)：暂停 2 秒，适合人眼可感知的等待或轻量退避 -
usleep(500000)：暂停 500 毫秒，适合高频轮询场景（慎用，优先考虑事件驱动） - 注意：CLI 模式下
set_time_limit(0)应配合使用，防止超时中断 - Web 环境禁用
sleep()控制流程——HTTP 请求有超时限制，挂起会导致连接阻塞
更复杂的间隔/依赖场景怎么办
当任务需满足“上一次执行完至少隔 X 时间才允许下一次”“必须等某个文件生成后再跑”“失败后指数退避”，单纯 cron 表达式不够，得引入外部协调机制：
- 用文件锁：
flock -x /tmp/myjob.lock php /path/to/script.php防止并发 - 记录最后执行时间戳到文件或数据库，脚本启动时读取并判断是否满足间隔条件
- 用 Redis 的
SET key value EX 300 NX实现带过期的分布式互斥锁 - 避免自己写“while+sleep”轮询等待外部信号——这本质是 busy-wait，消耗 CPU，应改用信号、inotify 或消息队列
真正难的不是让 PHP 睡一会儿，而是厘清“谁该决定什么时候运行”。cron 是触发器，不是控制器；sleep 是暂停指令，不是调度策略。混淆这两者，后面排查进程堆积、时间漂移、资源泄漏时，会反复掉进同一个坑。
