报错信息里的乱码字符是第一个需要关注的信号。`�\`这种显示异常通常说明脚本文件的编码格式出了问题，引擎无法正确解析文件内容。结合你“昨天改了点东西，第二次启动就报错”的情况，问题大概率出在编码、语法或缓存这三个环节。下面按从易到难的顺序，把这两个报错分别处理。
**先处理编码问题**
传奇服务端的脚本文件，包括Market_Def和QuestDiary目录下的所有.txt文件，引擎原生支持的是ANSI编码。如果你昨天用Windows系统自带的记事本编辑过这两个文件，它默认会以UTF-8格式保存，而UTF-8文件带有的BOM头会让引擎在读取时产生乱码，报错信息里的`�`符号就是典型的BOM头残留。
操作步骤：右键点击`D:\MirServer\Mir200\Envir\Market_Def\老兵\传送员_土城-3.txt`，选择“打开方式”中的“记事本”。在记事本里点击“文件”，选择“另存为”。在弹出的窗口底部找到“编码”选项，从下拉菜单中选择“ANSI”，然后覆盖保存原文件。对`D:\MirServer\Mir200\Envir\Market_Def\QFunction-0.txt`执行同样的操作。完成编码转换后，先不要急着启动服务端，继续往下排查语法问题。
**排查第181行和2341行的语法**
编码修正后，用记事本或Notepad++打开这两个文件，跳转到对应的行号。181行在传送员脚本中，2341行在QFunction-0.txt中。到达报错行后，优先检查以下几项内容。
查看该行是否使用了中文全角标点。传奇脚本引擎只识别英文半角符号，中文的逗号、冒号、括号、引号都会被判定为非法字符。检查这行的括号和引号是否成对出现，漏掉一个引号会导致后续所有代码被当作字符串处理，引发连锁报错。
检查该行所在的脚本结构是否完整。确认它前面最近的`#IF`语句有对应的`#ACT`或`#SAY`，并且逻辑块结尾有`break`或`goto`等结束指令。如果`#IF`后面缺少`#ACT`就直接跟了下一行命令，引擎在解析到报错行时仍处于未闭合的条件判断中，会把普通文本误判为脚本指令。`#IF`、`#ACT`、`#SAY`这些标签必须独立成行，`[@Main]`等段落头必须顶格书写，前面有任何空格都会导致引擎跳过该段。
如果报错行涉及`#CALL`命令，检查路径写法。`#CALL`的路径分隔符使用反斜杠`\`，路径开头不要带反斜杠。例如`#CALL[老兵\传送员_土城-3.txt]@传送`是正确写法，写成`#CALL[\老兵\传送员_土城-3.txt]@传送`会因为开头多了一个反斜杠而报错。同时确认被调用的目标文件确实存在于对应目录中。
**检查昨天修改的具体内容**
回顾一下昨天具体改了哪些内容。如果是在现有脚本中插入或修改了某一行命令，检查这行命令的拼写是否正确。传奇脚本的命令名称对拼写要求严格，`CHECKLEVELEX`写成`CHECKLEVEL`、`GIVE`写成`GIV`都会导致引擎无法识别。命令后面的参数格式也要确认，参数之间需要用空格分隔，运算符两侧通常需要留空格，例如写成`CHECKLEVELEX>44`而不是`CHECKLEVELEX>44`。
如果昨天新增了一段条件判断逻辑，确认每个`#IF`都有对应的`#ACT`，嵌套的`#IF`逻辑块是否完全独立。部分引擎对脚本嵌套层数有限制，过深的嵌套可能导致解析异常。新增的变量名不要与引擎保留字冲突，比如`GOLD`、`LEVEL`、`MAPNAME`这些系统关键字不能用作自定义变量名。
**清理脚本缓存**
第一次启动服务器时，引擎会将脚本加载到内存并可能生成缓存文件。如果昨天修改脚本后没有清理缓存，第二次启动时引擎可能同时加载了旧缓存和新修改的脚本，两者冲突触发报错。进入`MirServer\Mir200\Log`目录，找到`ScriptCache.dat`文件，如果存在就删除它。部分版本的缓存文件可能在其他位置，可以搜索整个Mir200目录下的`.dat`文件进行确认。删除缓存后，完全关闭M2Server进程，再重新启动。
**如果以上步骤都无法解决**
如果编码、语法、缓存都排查过之后仍然报错，最快的处理方式是回滚。如果你在修改之前有备份这两个脚本文件，直接用备份覆盖当前文件，重启服务端。如果没用备份，检查服务端压缩包或版本库中是否有原始版本的`传送员_土城-3.txt`和`QFunction-0.txt`，用原始文件替换后再重新做修改。
回滚之后，重新修改时每改完一处就保存并重启一次服务端，观察报错是否消失。一次只改一个地方，这样可以精确定位到底是哪一处修改引入了问题，而不是在多个改动混合的情况下反复试错。
**先处理编码问题**
传奇服务端的脚本文件，包括Market_Def和QuestDiary目录下的所有.txt文件，引擎原生支持的是ANSI编码。如果你昨天用Windows系统自带的记事本编辑过这两个文件，它默认会以UTF-8格式保存，而UTF-8文件带有的BOM头会让引擎在读取时产生乱码，报错信息里的`�`符号就是典型的BOM头残留。
操作步骤：右键点击`D:\MirServer\Mir200\Envir\Market_Def\老兵\传送员_土城-3.txt`，选择“打开方式”中的“记事本”。在记事本里点击“文件”，选择“另存为”。在弹出的窗口底部找到“编码”选项，从下拉菜单中选择“ANSI”，然后覆盖保存原文件。对`D:\MirServer\Mir200\Envir\Market_Def\QFunction-0.txt`执行同样的操作。完成编码转换后，先不要急着启动服务端，继续往下排查语法问题。
**排查第181行和2341行的语法**
编码修正后，用记事本或Notepad++打开这两个文件，跳转到对应的行号。181行在传送员脚本中，2341行在QFunction-0.txt中。到达报错行后，优先检查以下几项内容。
查看该行是否使用了中文全角标点。传奇脚本引擎只识别英文半角符号，中文的逗号、冒号、括号、引号都会被判定为非法字符。检查这行的括号和引号是否成对出现，漏掉一个引号会导致后续所有代码被当作字符串处理，引发连锁报错。
检查该行所在的脚本结构是否完整。确认它前面最近的`#IF`语句有对应的`#ACT`或`#SAY`，并且逻辑块结尾有`break`或`goto`等结束指令。如果`#IF`后面缺少`#ACT`就直接跟了下一行命令，引擎在解析到报错行时仍处于未闭合的条件判断中，会把普通文本误判为脚本指令。`#IF`、`#ACT`、`#SAY`这些标签必须独立成行，`[@Main]`等段落头必须顶格书写，前面有任何空格都会导致引擎跳过该段。
如果报错行涉及`#CALL`命令，检查路径写法。`#CALL`的路径分隔符使用反斜杠`\`，路径开头不要带反斜杠。例如`#CALL[老兵\传送员_土城-3.txt]@传送`是正确写法，写成`#CALL[\老兵\传送员_土城-3.txt]@传送`会因为开头多了一个反斜杠而报错。同时确认被调用的目标文件确实存在于对应目录中。
**检查昨天修改的具体内容**
回顾一下昨天具体改了哪些内容。如果是在现有脚本中插入或修改了某一行命令，检查这行命令的拼写是否正确。传奇脚本的命令名称对拼写要求严格，`CHECKLEVELEX`写成`CHECKLEVEL`、`GIVE`写成`GIV`都会导致引擎无法识别。命令后面的参数格式也要确认，参数之间需要用空格分隔，运算符两侧通常需要留空格，例如写成`CHECKLEVELEX>44`而不是`CHECKLEVELEX>44`。
如果昨天新增了一段条件判断逻辑，确认每个`#IF`都有对应的`#ACT`，嵌套的`#IF`逻辑块是否完全独立。部分引擎对脚本嵌套层数有限制，过深的嵌套可能导致解析异常。新增的变量名不要与引擎保留字冲突，比如`GOLD`、`LEVEL`、`MAPNAME`这些系统关键字不能用作自定义变量名。
**清理脚本缓存**
第一次启动服务器时，引擎会将脚本加载到内存并可能生成缓存文件。如果昨天修改脚本后没有清理缓存，第二次启动时引擎可能同时加载了旧缓存和新修改的脚本，两者冲突触发报错。进入`MirServer\Mir200\Log`目录，找到`ScriptCache.dat`文件，如果存在就删除它。部分版本的缓存文件可能在其他位置，可以搜索整个Mir200目录下的`.dat`文件进行确认。删除缓存后，完全关闭M2Server进程，再重新启动。
**如果以上步骤都无法解决**
如果编码、语法、缓存都排查过之后仍然报错，最快的处理方式是回滚。如果你在修改之前有备份这两个脚本文件，直接用备份覆盖当前文件，重启服务端。如果没用备份，检查服务端压缩包或版本库中是否有原始版本的`传送员_土城-3.txt`和`QFunction-0.txt`，用原始文件替换后再重新做修改。
回滚之后，重新修改时每改完一处就保存并重启一次服务端，观察报错是否消失。一次只改一个地方，这样可以精确定位到底是哪一处修改引入了问题，而不是在多个改动混合的情况下反复试错。