ThinkPHP6定时任务执行超时本质是系统中断、PHP超时机制或业务阻塞所致，需定位“谁杀进程”和“为何卡住”，而非仅调大set_time_limit()；须关闭PHP超时限制、重定向日志、注册SIGTERM处理器、分批处理数据并显式设置外部调用超时。
ThinkPHP6 定时任务执行超时，本质不是框架限制了时间，而是CLI 进程在 crontab 环境下被系统中断、或 PHP 自身超时机制触发、或业务逻辑阻塞未响应。真正要解决的，是定位“谁在杀进程”和“为什么卡住”，而不是简单调大 set_time_limit()。
一、确认是否真被 PHP 超时中断
TP6 命令行默认不设 max_execution_time 限制（CLI 模式下该 ini 值通常为 0），但以下情况仍可能触发超时：
- 你在命令类中手动调用了
set_time_limit(30) - 使用了某些扩展（如 cURL、PDO）自带的超时配置未重置
- Swoole Worker 模式下启用了
timeout配置
建议：
- 在
execute()开头显式关闭时间限制：set_time_limit(0); ini_set('max_execution_time', '0'); - 检查数据库连接、HTTP 请求、文件读写等外部操作是否设置了过短超时（如
Db::connect([... 'timeout' => 5 ...])）
二、防止 crontab 启动的进程被系统 kill
crontab 默认不继承终端会话，进程无 STDIN、stdout/stderr 若未重定向，遇到异常或信号（如 SIGTERM、OOM killer）会静默退出，看起来就像“超时”。
立即学习“PHP免费学习笔记（深入）”；
必须做三件事：
- 所有 crontab 条目末尾加日志重定向：
*/10 * * * * cd /var/www/myapp && /usr/bin/php think cron:sync-data >> /var/log/tp6-sync.log 2>&1
- 在命令类开头强制开启错误报告：
error_reporting(E_ALL); ini_set('display_errors', 0); ini_set('log_errors', 1); - 注册 SIGTERM 处理器（尤其用于清理 DB 连接、临时文件）：
pcntl_signal(SIGTERM, function() { Db::close(); exit(0); });
三、避免业务逻辑自身卡死或无限等待
常见陷阱包括：
- 循环中没做分页或 limit，一次查几万条数据导致内存爆满
- Redis/Memcached 连接未设超时，网络抖动时卡住几十秒
- 文件锁（
flock）未释放，后续任务一直阻塞 - 调用第三方 API 未设
timeout和connect_timeout
实操建议：
- 数据处理务必分批：用
chunk(500, function($items){...})替代get() - HTTP 请求统一走
think\facade\Http并显式设超时：Http::timeout(10)->connectTimeout(5)->get('https://api.example.com'); - 所有阻塞操作加 try-catch + 超时兜底逻辑，失败后记录并跳过，不中断整个任务
四、检查运行环境是否“假超时”
有时你以为任务超时了，其实是：
-
runtime/目录权限不对，写日志/缓存失败后静默退出 -
APP_ENV=production没显式设置，开发环境配置加载失败引发异常 - crontab 用户（如
root）与 Web 用户（如www-data）不一致，导致数据库 socket 路径不可达（localhostvs127.0.0.1）
验证方式：
- 手动切到 crontab 用户身份执行一次：
sudo -u www-data -i cd /var/www/myapp && /usr/bin/php think cron:sync-data
- 查看
/var/log/syslog或dmesg是否有 OOM killer 杀进程记录 - 用
strace -f -p <pid></pid>（若进程还能抓到）观察最后卡在哪一系统调用
不复杂但容易忽略
