死循环几乎全是人为逻辑错误，如条件表达式误用赋值而非判断、循环变量未更新或初始/终止条件矛盾，导致循环条件恒为真。
PHP for 循环死循环，几乎全是人为逻辑错误，不是语法缺陷，也不是 PHP 本身的问题。 它不会“自己”卡住，而是你写的三个表达式之间互相矛盾或缺失控制，导致条件永远为真。
条件表达式写成赋值而非判断
这是最隐蔽也最常踩的坑：把 $i 错写成 <code>$i = 10（单等号）。
-
for ($i = 0; $i = 10; $i++)—— 每次循环开始前都把$i设为 10，条件恒为真（非零即 true），无限执行 - 注意：
=是赋值，==或===才是判断；PHP 不报错，但行为完全失控 - 尤其在倒序写法中更易出错：
for ($i = 5; $i = 0; $i--)同样永不停止
递增/递减逻辑缺失或重复
循环变量不更新，或被多处修改，导致它根本“走不动”或“跳着走”。
- 漏写第三段：
for ($i = 0; $i → <code>$i始终是 0，条件永远成立 - 在循环体内又写了一次
$i++，而第三段还留着：for ($i = 0; $i → <code>$i每轮加两次，只处理 0、2、4…但最终仍会停，只是逻辑错乱 - 用
break或continue跳过递增逻辑，且没做兜底，也可能卡住
数组遍历时误信 count() 的稳定性
在循环条件里直接调用 count($arr)，同时循环体中又 unset() 或 array_push()，就会让边界动态漂移。
立即学习“PHP免费学习笔记（深入）”；
for ($i = 0; $i → 每删一个，<code>count()减 1，但$i还在加，极易跳过元素或越界访问-
count($arr)每次都重新计算，大数组下性能差，且结果不可预测 - 正确做法是提前缓存：
$len = count($arr); for ($i = 0; $i ，或改用 <code>foreach - 关联数组或键不连续时，
$arr[$i]直接触发Undefined offset，但循环本身未必中断——错误抑制后可能掩盖死循环迹象
无限循环写法被误用
for(;;) 本身合法，但必须靠内部 break 或 exit() 退出；一旦漏掉或条件写错，就是纯死循环。
-
for(;;) { if (some_condition()) break; }—— 看似安全，但如果some_condition()永远不返回 true，就卡死 - 配合
usleep()或网络请求时更危险：外部依赖失败，内部无 fallback，进程 CPU 占满却无日志输出 - 这种写法常见于 CLI 长任务或 Swoole Worker，调试时需用
gdb -p PID+bt查调用栈定位卡点
真正难排查的不是“哪里写错了”，而是“为什么看起来没写错”。比如变量作用域污染：$i 在上一个 for 里没重置，下一个 for ($i = 0; ...) 实际从非零值开始；或者错误抑制符 @ 掩盖了 Undefined offset 导致后续逻辑静默失效。这些细节不打日志、不看变量生命周期，几乎无法靠肉眼发现。
