ThinkPHP本身不自带死循环，问题根源在于业务代码、扩展或配置不当引发的无限执行；需区分真死循环（CPU 100%）与I/O阻塞（如数据库、Redis等待），通过日志、进程监控、GDB/Process Explorer栈追踪精准定位事件监听递归、模型自我回调、中间件重定向循环等高频诱因，并用计数保护、标记位、白名单及超时限制修复预防。
ThinkPHP本身不自带死循环，但业务代码、扩展调用或配置不当可能引发无限执行。排查重点不在框架层，而在你写的逻辑是否构成不可退出的循环，以及是否被缓存、钩子、中间件等机制意外放大。
确认是不是真死循环
先排除“假卡顿”：比如数据库查询阻塞、远程API超时、文件锁未释放、Redis连接等待等。这些表现像死循环，实则是I/O阻塞。
- 打开命令行，运行php think run启动内置服务器，访问接口看是否响应；若卡住，再用Ctrl+C中断，观察是否立即退出——能中断说明不是CPU级死循环，而是阻塞等待
- 在疑似循环处加error_log("in loop step: " . $i, 3, 'php_loop.log')，并配合usleep(10000)防刷屏；刷新日志看数字是否持续增长
- 用ps aux | grep php（Linux）或任务管理器（Windows）查进程状态：若%CPU 接近100%且持续不降，才是典型死循环特征
检查常见死循环诱因
ThinkPHP项目中高频出问题的几个位置：
- 事件监听/行为扩展：在app/event.php里注册了监听器，而监听器内部又触发了相同事件（如UserLogin监听器里调用了Event::trigger('UserLogin')），形成递归触发
- 模型事件回调：在UserModel中定义了onAfterUpdate，里面又调用了$this->save()，没加判断条件就导致反复更新→触发→再更新
- 中间件嵌套跳转：A中间件检查登录态，未登录则redirect('/login')；B中间件又对/login做权限校验，再次重定向回A，形成302循环
- 模板include嵌套：view/a.html里{include file="b"}，b.html里又{include file="a"}，开启模板编译缓存后可能不报错但页面白屏或超时
快速定位到具体代码行
不用猜，用工具直接抓栈：
立即学习“PHP免费学习笔记（深入）”；
- Linux下找到卡住的PHP进程PID：ps aux | grep 'php.*your_script'
- 用GDB附加：gdb -p PID，然后输入bt（backtrace），看最后一层调用是否落在你的控制器、模型或公共函数里
- Windows下可配合Process Explorer（微软官方工具），右键php.exe → Properties → Threads → 查看哪个线程CPU占用高，再点Stack查看调用链
- 更轻量方式：在入口public/index.php开头加register_shutdown_function(function(){var_dump(debug_backtrace());});，虽然不能捕获死循环，但能暴露最后正常执行到哪一行
修复与预防建议
定位到代码后，修复要兼顾安全和可维护性：
- 所有while(true)或for(;;)必须配明确退出条件，并加计数保护：$max = 100; while($cond && --$max > 0) { ... }
- 模型事件中避免无条件自我调用，改用标记位：if (!$this->skipEvent) { $this->skipEvent = true; $this->save(); }
- 中间件重定向前加路径白名单判断，防止循环跳转
- 开发期启用set_time_limit(30)，线上环境用max_execution_time=30（php.ini），让失控脚本自动终止，留出错误日志
- 上线前跑一次静态分析：phpstan analyse app/ --level=5，它能发现部分潜在无限递归调用
