死循环是传奇脚本编写中最容易踩的坑，表现为NPC无法对话、M2Server占用飙升、游戏卡顿甚至服务端直接崩溃。死循环的本质是同一段代码被反复执行且没有退出条件，但在传奇脚本体系中，它的触发路径远比普通的while循环复杂，涉及GOTO跳转、触发字段回调、定时器、掉落事件等多个层面。
**GOTO跳转形成的无条件循环**
GOTO是传奇脚本中最常用的跳转命令，也是最容易写出死循环的地方。典型错误写法是：[@Main]#ACTGOTO@Main。这段脚本执行后会立刻跳回@Main，形成无限循环，M2Server的CPU占用瞬间拉满，玩家客户端卡死在对话界面。另一种隐蔽写法是：[@Main]#IFCHECKLEVELEX>0#ACTGOTO@Main，条件判断看起来有逻辑，但CHECKLEVELEX>0对绝大多数角色恒为真，效果等同于无条件跳转。
排查这类问题的方法是在每个GOTO命令前确认跳转目标段的末尾有Break命令，或者跳转目标段最终会执行到某个终止节点。Break的作用是终止当前脚本执行，不会跳转到任何其他段。如果一个GOTO跳转的目标段末尾没有Break且没有其他跳转出口，脚本执行到该段末尾后会自动回到上一段继续执行，形成隐式循环。
**触发字段回调形成的链式循环**
比GOTO更隐蔽的是触发字段之间的互相调用。例如在QFunction-0.txt中定义了[@Attack]触发，玩家攻击怪物时触发该段脚本，脚本中调用了一个NPC对话命令，NPC对话又触发了[@Main]段，而[@Main]段中执行了某个动作再次触发了[@Attack]。这种循环不会表现为CPU占满，而是表现为玩家每次攻击后NPC对话框反复弹出，或者攻击动作被无限重复触发。
排查这类问题的思路是梳理触发链条：谁调用了谁，谁又触发了谁。在每个触发段的开头加一条SENDMSG5触发[@XXX]的输出语句，观察游戏内的消息输出频率。如果某条消息在短时间内被输出几十次，说明该段脚本陷入了循环调用。找到循环的闭环节点后，在其中一个环节加入条件判断，比如检测某个变量的值，满足条件时不再执行后续命令。
**定时器与机器人脚本的自我触发**
定时器脚本（Robot.txt）和机器人脚本（RobotManage.txt）中的定时执行逻辑如果配置不当，也会形成死循环。典型场景是一个定时器每分钟执行一次，脚本中修改了某个变量，而另一个定时器检测到该变量变化后又修改了另一个变量，第二个变量的变化又反过来触发第一个定时器的执行条件。两个定时器互相触发，执行频率远高于设定的时间间隔，造成M2Server负载持续偏高。
解决方式是将相互依赖的定时器合并为一个定时器执行，避免多个定时器之间通过变量互相触发。如果确实需要多个定时器协作，在每个定时器的执行条件中加入时间间隔判断，例如通过GETGAMETIME获取当前时间戳，与上一次执行的时间戳比较，两次执行间隔小于设定值时直接跳过。
**掉落触发与物品回收的循环**
在@HumDropItem或@DropItem等掉落触发中执行物品回收或重新给予物品的操作，会形成掉落循环。例如玩家死亡掉落了一把武器，@HumDropItem触发后脚本判断该武器是绑定物品，执行了GIVE命令将武器还给玩家，玩家再次死亡后武器再次掉落，再次触发@HumDropItem，再次GIVE。这个过程在玩家每次死亡时都会重复，虽然不会造成CPU占满，但会导致物品复制或掉落记录异常膨胀。
正确的处理方式是在@HumDropItem中只执行StopDropItem阻止掉落，不要用GIVE命令给予替代物品。如果需要补偿玩家，应该在死亡事件处理完成之后，通过延时触发或下一次登录时触发来发放补偿物品。GOM引擎中可以在@HumDropItem中设置一个变量标记“本次死亡已处理”，然后在其他触发段中检测该标记并清除，避免重复处理。
**WHILE循环的退出条件缺失**
部分引擎支持WHILE循环命令，用于批量处理背包物品或地图中的怪物。WHILE循环的退出条件通常依赖于循环变量的自增或某个数据的递减。常见的错误写法是：WHILECHECKITEMCOUNT物品名>0#ACTTAKE物品名1。这段脚本的逻辑是当背包中还有该物品时拿走一个，直到拿完为止。表面上看逻辑正确，但如果TAKE命令因为物品绑定、装备中无法拿取等原因没有实际扣除物品数量，CHECKITEMCOUNT的检测结果始终大于0，WHILE循环永远不会退出，M2Server卡死在循环中。
修复方法是在WHILE循环中加入计数器变量，每次循环自增1，当计数器达到某个上限（例如100次）时强制退出循环。脚本写法为：MOVN990WHILECHECKITEMCOUNT物品名>0#ACTTAKE物品名1INCN991#IFCHECKVARN99>100#ACTBREAK。这样即使TAKE命令未生效，循环也会在100次后强制终止，避免死循环。
**变量未初始化导致的逻辑异常循环**
变量未初始化时，引擎会将其视为0或空字符串。如果脚本的逻辑依赖变量值进行条件判断，未初始化的变量可能导致条件判断结果与预期相反，进而进入错误的执行分支，最终形成循环。例如一个脚本判断转生次数变量，如果变量未初始化时值为0，脚本走“未转生”分支，而该分支中又执行了转生操作并将变量设为0，下一次执行时变量仍为0，再次走“未转生”分支，形成循环。
解决方式是在脚本的最开始处对所有使用的变量进行显式初始化。在QManage.txt的[@Login]段中使用MOV命令将变量赋初值，确保玩家上线时变量有确定的值。HUMAN类型变量在VAR声明后如果没有LOADVAR赋值，引擎默认值为0，但0在部分逻辑中可能是有意义的有效值，与未初始化的默认值无法区分。可以在声明时赋一个哨兵值（例如-1），业务逻辑中先判断变量是否为哨兵值，如果是则执行初始化操作，否则按正常逻辑处理。
**触发脚本中的GOTO跨文件跳转**
GOTO命令支持跨文件跳转，格式为GOTO@XXX，其中目标段可以在另一个脚本文件中。跨文件跳转的死循环更难排查，因为两个脚本文件可能分别由不同的开发者编写，互相不知道对方的跳转逻辑。例如A脚本的[@Main]跳转到B脚本的[@Process]，B脚本的[@Process]在处理完成后跳转回A脚本的[@Main]，如果中间没有Break或条件判断拦截，就会形成跨文件循环。
排查时需要在所有涉及的脚本文件中搜索GOTO命令，列出每个跳转的源段和目标段，绘制跳转关系图。如果图中存在环，说明有循环跳转。消除环的方式是在环中的某一个跳转前加入条件判断，当满足特定条件时不再跳转而是执行Break。
**M2Server假死与死循环的区分**
并不是所有脚本卡顿都是死循环造成的。M2Server假死可能由内存不足、数据库连接超时、大量怪物同时触发脚本等原因引起。区分方法是打开任务管理器观察M2Server的CPU占用。死循环时CPU占用通常接近100%且持续不降；假死时CPU占用可能很低，但程序无响应。内存泄漏导致的假死会伴随内存占用持续增长。确认是死循环后，使用M2Server控制台的脚本调试功能逐步执行脚本，观察在哪一行命令后卡住。部分引擎支持在脚本中加入PRINTDEBUG命令输出调试信息，在M2控制台的调试窗口中可以看到脚本执行的实时日志。
**GOTO跳转形成的无条件循环**
GOTO是传奇脚本中最常用的跳转命令，也是最容易写出死循环的地方。典型错误写法是：[@Main]#ACTGOTO@Main。这段脚本执行后会立刻跳回@Main，形成无限循环，M2Server的CPU占用瞬间拉满，玩家客户端卡死在对话界面。另一种隐蔽写法是：[@Main]#IFCHECKLEVELEX>0#ACTGOTO@Main，条件判断看起来有逻辑，但CHECKLEVELEX>0对绝大多数角色恒为真，效果等同于无条件跳转。
排查这类问题的方法是在每个GOTO命令前确认跳转目标段的末尾有Break命令，或者跳转目标段最终会执行到某个终止节点。Break的作用是终止当前脚本执行，不会跳转到任何其他段。如果一个GOTO跳转的目标段末尾没有Break且没有其他跳转出口，脚本执行到该段末尾后会自动回到上一段继续执行，形成隐式循环。
**触发字段回调形成的链式循环**
比GOTO更隐蔽的是触发字段之间的互相调用。例如在QFunction-0.txt中定义了[@Attack]触发，玩家攻击怪物时触发该段脚本，脚本中调用了一个NPC对话命令，NPC对话又触发了[@Main]段，而[@Main]段中执行了某个动作再次触发了[@Attack]。这种循环不会表现为CPU占满，而是表现为玩家每次攻击后NPC对话框反复弹出，或者攻击动作被无限重复触发。
排查这类问题的思路是梳理触发链条：谁调用了谁，谁又触发了谁。在每个触发段的开头加一条SENDMSG5触发[@XXX]的输出语句，观察游戏内的消息输出频率。如果某条消息在短时间内被输出几十次，说明该段脚本陷入了循环调用。找到循环的闭环节点后，在其中一个环节加入条件判断，比如检测某个变量的值，满足条件时不再执行后续命令。
**定时器与机器人脚本的自我触发**
定时器脚本（Robot.txt）和机器人脚本（RobotManage.txt）中的定时执行逻辑如果配置不当，也会形成死循环。典型场景是一个定时器每分钟执行一次，脚本中修改了某个变量，而另一个定时器检测到该变量变化后又修改了另一个变量，第二个变量的变化又反过来触发第一个定时器的执行条件。两个定时器互相触发，执行频率远高于设定的时间间隔，造成M2Server负载持续偏高。
解决方式是将相互依赖的定时器合并为一个定时器执行，避免多个定时器之间通过变量互相触发。如果确实需要多个定时器协作，在每个定时器的执行条件中加入时间间隔判断，例如通过GETGAMETIME获取当前时间戳，与上一次执行的时间戳比较，两次执行间隔小于设定值时直接跳过。
**掉落触发与物品回收的循环**
在@HumDropItem或@DropItem等掉落触发中执行物品回收或重新给予物品的操作，会形成掉落循环。例如玩家死亡掉落了一把武器，@HumDropItem触发后脚本判断该武器是绑定物品，执行了GIVE命令将武器还给玩家，玩家再次死亡后武器再次掉落，再次触发@HumDropItem，再次GIVE。这个过程在玩家每次死亡时都会重复，虽然不会造成CPU占满，但会导致物品复制或掉落记录异常膨胀。
正确的处理方式是在@HumDropItem中只执行StopDropItem阻止掉落，不要用GIVE命令给予替代物品。如果需要补偿玩家，应该在死亡事件处理完成之后，通过延时触发或下一次登录时触发来发放补偿物品。GOM引擎中可以在@HumDropItem中设置一个变量标记“本次死亡已处理”，然后在其他触发段中检测该标记并清除，避免重复处理。
**WHILE循环的退出条件缺失**
部分引擎支持WHILE循环命令，用于批量处理背包物品或地图中的怪物。WHILE循环的退出条件通常依赖于循环变量的自增或某个数据的递减。常见的错误写法是：WHILECHECKITEMCOUNT物品名>0#ACTTAKE物品名1。这段脚本的逻辑是当背包中还有该物品时拿走一个，直到拿完为止。表面上看逻辑正确，但如果TAKE命令因为物品绑定、装备中无法拿取等原因没有实际扣除物品数量，CHECKITEMCOUNT的检测结果始终大于0，WHILE循环永远不会退出，M2Server卡死在循环中。
修复方法是在WHILE循环中加入计数器变量，每次循环自增1，当计数器达到某个上限（例如100次）时强制退出循环。脚本写法为：MOVN990WHILECHECKITEMCOUNT物品名>0#ACTTAKE物品名1INCN991#IFCHECKVARN99>100#ACTBREAK。这样即使TAKE命令未生效，循环也会在100次后强制终止，避免死循环。
**变量未初始化导致的逻辑异常循环**
变量未初始化时，引擎会将其视为0或空字符串。如果脚本的逻辑依赖变量值进行条件判断，未初始化的变量可能导致条件判断结果与预期相反，进而进入错误的执行分支，最终形成循环。例如一个脚本判断转生次数变量，如果变量未初始化时值为0，脚本走“未转生”分支，而该分支中又执行了转生操作并将变量设为0，下一次执行时变量仍为0，再次走“未转生”分支，形成循环。
解决方式是在脚本的最开始处对所有使用的变量进行显式初始化。在QManage.txt的[@Login]段中使用MOV命令将变量赋初值，确保玩家上线时变量有确定的值。HUMAN类型变量在VAR声明后如果没有LOADVAR赋值，引擎默认值为0，但0在部分逻辑中可能是有意义的有效值，与未初始化的默认值无法区分。可以在声明时赋一个哨兵值（例如-1），业务逻辑中先判断变量是否为哨兵值，如果是则执行初始化操作，否则按正常逻辑处理。
**触发脚本中的GOTO跨文件跳转**
GOTO命令支持跨文件跳转，格式为GOTO@XXX，其中目标段可以在另一个脚本文件中。跨文件跳转的死循环更难排查，因为两个脚本文件可能分别由不同的开发者编写，互相不知道对方的跳转逻辑。例如A脚本的[@Main]跳转到B脚本的[@Process]，B脚本的[@Process]在处理完成后跳转回A脚本的[@Main]，如果中间没有Break或条件判断拦截，就会形成跨文件循环。
排查时需要在所有涉及的脚本文件中搜索GOTO命令，列出每个跳转的源段和目标段，绘制跳转关系图。如果图中存在环，说明有循环跳转。消除环的方式是在环中的某一个跳转前加入条件判断，当满足特定条件时不再跳转而是执行Break。
**M2Server假死与死循环的区分**
并不是所有脚本卡顿都是死循环造成的。M2Server假死可能由内存不足、数据库连接超时、大量怪物同时触发脚本等原因引起。区分方法是打开任务管理器观察M2Server的CPU占用。死循环时CPU占用通常接近100%且持续不降；假死时CPU占用可能很低，但程序无响应。内存泄漏导致的假死会伴随内存占用持续增长。确认是死循环后，使用M2Server控制台的脚本调试功能逐步执行脚本，观察在哪一行命令后卡住。部分引擎支持在脚本中加入PRINTDEBUG命令输出调试信息，在M2控制台的调试窗口中可以看到脚本执行的实时日志。