脚本死循环出现时，M2引擎会弹出报错或直接卡死。处理这类问题分两步走：先调整引擎保护参数解决误报，再定位脚本本身逻辑漏洞。按顺序操作即可。
**一、调整引擎循环限制参数（临时解决）**
大多数死循环报错其实是引擎保护阈值设得太低，脚本正常跳转次数稍多就被拦截。修改服务端根目录下的配置文件来放宽限制。
1. **定位文件**：打开服务端文件夹，进入`Mir200`目录，找到`!Setup.txt`文件。用记事本或文本编辑器打开。
2. **修改参数**：在文件中搜索`ScriptGotoCountLimit`。默认值通常为10或50，数值过小时正常多段跳转脚本也会触发保护机制被判定异常。将该参数改为`50000`或`99999`均可，保存文件。
3. **重启引擎**：关闭并重新启动M2Server程序，让新参数生效。这一步必须执行，否则修改不生效。
调整后如果报错消失，说明问题出在参数而非脚本逻辑。若报错仍在，继续排查脚本本身。
**二、通过报错日志定位问题脚本**
参数调大后仍报错，说明脚本确实存在无限循环。M2的报错信息是定位源头最快途径。
1. **读取报错内容**：M2弹出死循环提示时，日志窗口同步记录报错路径。例如`[脚本死循环] NPC:VIP泡点 位置:3(327:319) 命令:GOTO @修炼5551`，这串信息直接告诉你问题出在VIP泡点NPC脚本的`GOTO @修炼5551`这一句。
2. **对照路径查找**：根据报错中的NPC名称或脚本文件名，在服务端`Envir\Market_Def`或`Envir\QuestDiary`目录下找到对应脚本文件，定位到报错行数。
**三、脚本逻辑层面的高频诱因**
如果M2没给出明确报错路径，或者报错指向的代码看起来没问题，重点检查以下几类写法：
* **GOTO跳转形成闭环**：一个`#ACT`块中连续写多个`GOTO @xxx`，或者脚本A跳转脚本B、脚本B又跳转回脚本A，形成互相调用的闭环，无限递归下去必定触发保护。
* **循环判定条件永远为真**：比如用`GetRandomText`读取文本内容时，没有先清空接收变量。如果读取到的内容是空值，变量会继承上次的值而不是变成空，导致判定条件始终成立，循环永远退不出。
* **变量未重置或计数未递增**：任务脚本中杀怪数量变量未执行递增操作（如遗漏`INC N杀怪数 1`），系统判定始终未完成，反复触发同一段逻辑。
**四、脚本写法层面的预防措施**
根治死循环，写脚本时遵守几条硬规矩：
* **少用GOTO，用DELAYGOTO替代**：`GOTO`是无条件立即跳转，容易踩坑。改用`DELAYGOTO 2 @xxx`（单位毫秒），给脚本执行留出缓冲，极大降低死循环概率。
* **每个跳转必须有退出出口**：循环逻辑中必须设置明确的终止条件，比如超时退出、次数上限、变量清空判定。任何跳转分支最终都要指向一个结束点，不能出现无路可走的死胡同。
* **避免#CALL滥用**：简单脚本内容直接写在QF（QFunction-0.txt）里，不要什么事都用`#CALL`调用外部文件。调用层级越多，跳转路径越复杂，出问题的概率越大。
