max_input_time 不防死循环，它仅限制接收用户输入的最长时间；防死循环应靠 max_execution_time（总执行时间上限）和 memory_limit（内存限制），并配合代码级防护如显式退出条件与计数器。
max_input_time 不是用来防死循环的
max_input_time 控制的是 PHP 等待用户输入（如 POST/GET 数据）完成的最长时间，单位是秒。它和脚本执行逻辑完全无关，哪怕你写了个 while (true)，只要输入早已收完，这个参数就彻底失效了。线上看到死循环还去调 max_input_time，属于方向性错误。
真正该盯紧的两个 ini 配置项
防死循环必须靠这两个：
-
max_execution_time：脚本总执行时间上限，默认 30 秒。超时后 PHP 强制中止，抛出Fatal error: Maximum execution time of X seconds exceeded -
memory_limit：内存耗尽也会中断执行，但不如时间限制可靠——有些死循环只占 CPU 不吃内存
修改方式分三层：
- 运行时用
set_time_limit(5)动态设（注意：设为 0 表示取消限制，慎用） -
php.ini 中改全局值：
max_execution_time = 10 - Apache/Nginx 下可通过
php_admin_value max_execution_time 10强制覆盖
为什么光靠配置不够？得加代码防护
配置只是兜底，不能替代逻辑修复。真实场景里，以下做法更可靠：
- 所有
while (true)或递归函数，必须带显式退出条件，且条件变量在循环体内被真实更新 - 加计数器防意外：
$i = 0; while ($condition && $i++ - 加时间戳判断：
$start = microtime(true); while ($condition && (microtime(true) - $start) - 避免在循环里做阻塞操作（如未设 timeout 的
file_get_contents()、cURL），否则可能卡住但不超时
线上已跑飞怎么办？别只等超时
等 max_execution_time 触发太被动。更有效的现场干预是：
- 用
ps aux | grep php找出高 CPU 的进程 PID - 确认是哪个脚本：
lsof -p PID | grep .php - 直接
kill -9 PID终止，比等超时快得多 - 查
slowlog（如果启用了 opcache + xdebug 或 php-fpm slow log），定位卡点
真正难处理的不是“怎么终止”，而是“为什么没在开发阶段发现”——循环体里少一行 $i++，或递归漏掉一个 return，上线后就是雪球。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
