set_time_limit仅限制当前php进程执行时间，对exec等启动的子进程无效，无法终止阻塞的数据库连接或curl调用，易导致僵尸进程、连接泄漏和oom。
PHP 任务调度框架本身不提供进程级超时强制终止能力，所有“超时终止”必须由外部机制介入——要么靠 pcntl_alarm + 信号中断（仅 CLI、Linux/macOS），要么靠父进程杀子进程（需手动管理 PID），要么靠系统级工具（如 timeout 命令）。直接在 Laravel Scheduler 或原生 cron 脚本里写 set_time_limit(30) 是无效的，它只限制 PHP 执行时间，不杀进程。
为什么 set_time_limit 不会终止正在运行的子进程
set_time_limit 只作用于当前 PHP 进程的脚本执行计时器，对 exec()、shell_exec()、proc_open() 启动的子进程完全无感知。子进程可能卡在数据库连接、cURL 等阻塞调用上，而主脚本早已退出，但子进程还在后台挂着。
- 现象：日志显示任务“已启动”，但数据库没更新、短信没发、Redis 没写入，
ps aux | grep php却能看到残留进程 - 根本原因：PHP 的超时机制是单进程内建的，不是操作系统级的资源管控
- 后果：僵尸进程堆积、数据库连接泄漏、内存缓慢增长，数天后触发 OOM
用 timeout 命令包装 CLI 任务（最简单可靠）
Linux timeout 命令能真正发送 SIGTERM（或 SIGKILL）信号终止整个进程树，比任何 PHP 内部函数都底层、更干净。
- 正确写法：
*/5 * * * * timeout --signal=SIGKILL 120 /usr/bin/php /var/www/artisan schedule:run >> /var/log/schedule.log 2>&1 - 不要省略
--signal=SIGKILL：默认SIGTERM可被忽略，SIGKILL强制不可捕获 - 时间单位是秒，120 表示硬性上限 2 分钟，超时立即杀掉包括所有子进程
- 注意：Windows 不支持
timeout，此方案仅限 Linux/macOS 生产环境
用 pcntl_fork + pcntl_alarm 实现自控超时（需严格条件）
这是唯一能在 PHP 内部实现“到点就停”的方式，但门槛高、易出错，仅建议有明确控制需求且环境可控的场景使用。
- 必须满足：CLI SAPI、启用
pcntl扩展、禁用opcache.enable_cli=0（否则pcntl_signal失效） - 关键陷阱：
pcntl_alarm只对当前进程有效，fork 出的子进程需各自调用，且不能在多线程或 FPM 下使用 - 最小可行示例：
pcntl_signal(SIGALRM, function () {
exit(124); // 超时退出码
});
pcntl_alarm(60); // 60秒后发 SIGALRM
// 此处放你的耗时逻辑，比如 file_get_contents 或 PDO 查询
pcntl_alarm(0); // 清除定时器，防止后续误触发
- 别在 Laravel 的
Artisan::call()里嵌套这套逻辑——FPM 请求中 fork 会污染 worker 进程
避免依赖框架调度器本身的“超时”字段
像 Laravel 的 $schedule->command('foo')->runInBackground()->after(60) 这类写法，只是设置“最多等 60 秒启动”，不是“运行超时就杀”，而且 runInBackground() 底层仍是 exec()，不受 PHP 超时控制。
- 真实风险：你认为“超时自动结束”，其实只是主脚本不管了，子进程继续跑，甚至可能重复执行（cron 每分钟再触发一次）
- 替代做法：把长任务拆成“提交 → 查询状态 → 完成回调”三步，用 Redis 锁 + 过期时间（
SETNX task:123 lock EX 300）防重入 - 监控重点：不是看调度器日志是否报错，而是定期查
ps aux --sort=-etime | head -20，找运行超 5 分钟的 PHP 进程
真正可靠的超时终止永远发生在进程边界之外：系统命令、信号、守护进程管理器。PHP 层能做的只是配合退出、清理资源、记录状态——别指望它替你杀掉卡死的 cURL 或 MySQL 连接。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
