CLI 下 set_time_limit(0) 本就无效，因默认即不限时；真正中断脚本的是系统 ulimit、Docker timeout 或平台策略，而非 PHP；循环中反复调用反而危险，应改用 microtime(true) 主动计时。
CLI 模式下 set_time_limit(0) 看似没用，其实是它本来就不该“起效”
CLI 模式下 set_time_limit() 不是“失效”，而是行为与 Web 完全不同：它的默认值就是 0（不限时），所以调用 set_time_limit(300) 实际是把“无限”改成“300 秒”，而多数人误以为是在“延长”。一旦脚本已运行超时，set_time_limit() 就再无机会执行——它只在超时发生前有效。
CLI 下真正会中断脚本的，不是 PHP 而是系统或容器
常见现象：明明 set_time_limit(0) 写了，脚本还是被杀。这不是 PHP 的问题，而是外层限制在起作用：
-
ulimit -t设置了 CPU 时间上限（比如 300），到点由系统直接SIGKILL，PHP 层完全无感知 - Docker 容器配置了
timeout或livenessProbe，会在 PHP 超时前先终止进程 - Windows 命令行窗口被手动关闭、PowerShell 脚本设置了
-TimeoutSec，或任务计划程序强制结束 - 某些托管 CLI 环境（如 GitHub Actions、部分云函数）会忽略
set_time_limit，按平台策略硬中断
为什么在循环里反复调用 set_time_limit(0) 反而危险
这不是续命，是主动放弃保护：
- 每次调用
set_time_limit(0)都重置计时器，但若循环中存在阻塞 I/O（如fread()等待网络响应）、死锁或未设退出条件，进程就彻底失控 - CLI 虽无 worker 池压力，但资源耗尽（内存泄漏、文件句柄占满）仍会导致系统级失败，且无错误日志提示
- 正确做法是用
microtime(true)主动测时，在关键节点判断是否超阈值并exit()或抛异常，比依赖计时器更可靠
CLI 和 Web 的超时机制根本不在同一层
Web 请求超时是多层叠加的：浏览器连接空闲超时 → Nginx fastcgi_read_timeout → PHP-FPM request_terminate_timeout → PHP 层 max_execution_time。而 CLI 只有两层：PHP 自身（默认不限）→ 操作系统/容器/启动器。所以排查时必须分清中断来源：
立即学习“PHP免费学习笔记（深入）”；
- 执行
php --ini确认加载的php.ini是否真生效（有些 CLI 启动带-d max_execution_time=30参数覆盖） - 运行
ulimit -t查看当前 shell 的 CPU 时间限制 - 如果是 Docker，检查
docker run --stop-timeout或healthcheck配置 - 用
strace -e trace=timer_settime,kill php script.php（Linux）观察是否收到系统信号
最易被忽略的是：你以为在调 PHP 超时，其实早被操作系统或容器 runtime 截断了。
