传奇架设后每次大退都要重新加载的排查与解决办法

一、先分清是哪一种“重新加载”

同样是“每次大退都要重新加载”，实际对应四种完全不同的故障，混在一起查只会越改越乱。

第一种：大退后再进游戏，客户端重新下载资源，进度条从头跑一遍，微端提示正在更新。这是资源索引或缓存的问题。

第二种：大退后再登录，人物等级、背包、装备回到之前的状态，像没玩过一样。这是存档没写进去，属于数据持久化问题。

第三种：大退后重连，卡在选角色或进地图那一步很久，服务端控制台刷一堆读取日志。这是服务端启动项或缓存机制的问题。

第四种：服务端每次重启都要重新加载地图、脚本、数据库，启动特别慢。这是正常现象被误认为故障，或者确实存在配置缺陷。

先对照自己的表现锁定类型，再往下找对应段落。

二、第一种：客户端反复重新下载资源

这是最常见的情况，尤其是用了微端或登录器自带资源更新的架设环境。

缓存目录被清理

微端和登录器会在客户端目录或用户目录下生成缓存文件夹，名字常是 Cache、Temp、Update、P2P 之类。如果这个目录放在系统盘临时文件夹里，或者被安全软件、清理工具当成垃圾定期清空，下次启动就会判定为没有资源，重新拉取一遍。

处理办法：把缓存路径改到客户端根目录下一个固定的子目录，用绝对路径；把这个目录加进安全软件的白名单；关掉各类管家的自动清理计划任务。

资源索引文件每次都在变

微端的更新逻辑是比较本地索引和服务端索引的差异。如果服务端的索引文件每次启动都被重新生成（比如版本号取的是当前时间戳，或者打包脚本每次都全量重建），客户端会认为资源全部变更，于是整包重下。

处理办法：检查微端服务端的打包设置，确认增量更新已开启、版本号改为按内容变更递增而不是按时间生成。打包时只把真正改过的文件算进新版本。

P2P共享没开或节点单一

很多登录器用P2P分发资源，玩家之间互相传。如果只有你一个节点，或者P2P端口被防火墙挡住，每次都是单机从服务器硬拉，速度极慢且容易中断重来。放行对应端口，并确认种子文件没有被覆盖。

资源目录权限不足

服务端放在需要管理员权限才能写的目录时，微端写入缓存失败，下一次启动依旧判定为未更新。把整套环境移到非系统盘的纯英文短路径，取消只读属性，用管理员身份运行。

传输模式导致文件损坏

从本地传到服务器时，如果FTP用了文本模式，wil、map这类二进制文件会被转码损坏，校验对不上就会反复重试下载。传输模式必须设为二进制，传完后比对一下文件大小。

三、第二种：大退后人物数据回档

表现是玩了一晚上，大退再进，等级、金币、装备回到上线时的样子。这不是“重新加载”，是存档根本没落盘。

日志服务器没起来

角色存档、物品记录通常走 LogServer。前面提到过，LogServer 起不来或被取消掉，短期看着能玩，一到存档环节就丢数据。先确认 LogServer 单独双击能正常监听，再谈其他。

存档目录没写权限或磁盘满了

Mir200 下的 Save、UserData、Castle 等目录如果写不进去，内存里有数据，关机就没了。检查磁盘剩余空间，检查目录权限，检查杀毒软件有没有拦截写入。

服务端被强制结束进程

直接杀进程、断电、蓝屏，都会导致内存里的存档没来得及 flush 到磁盘。正常关闭的顺序是先停 M2，再停网关，最后停 DBServer 和 LogServer。测试时养成习惯，不要图快直接关窗口。

多开或同账号顶号

同一个账号在两个登录器上同时在线，后上的会把先上的存档覆盖掉，表现就是“刚才打的装备没了”。部分引擎的存档是按角色名建文件，顶号时互相踩踏。确认没有残留进程在后台挂着。

数据库别名指向了旧的库

BDE 别名 PATH 指错了目录，或者你复制了一份服务端做测试但忘了改别名，结果读写的是另一套库。看起来像回档，其实是读错了地方。用 DBCommander 打开别名，看一眼表里的内容是不是你当前玩的这个号。

四、第三种：大退后重连卡在读条

网关连接池没释放

玩家大退时，RunGate 那边的会话如果没有正常释放，端口或连接数占着不放，重连就要等超时。这在并发稍高时更明显。表现是第一次进很快，大退后再进卡几十秒。重启服务端立刻恢复正常，过一阵又犯。

处理办法：确认网关配置里的超时时间、最大连接数合理；检查有没有大量 TIME_WAIT 堆积；必要时在系统层面调短 TCP 回收时间。

M2 重复读档

部分引擎在玩家重连时会重新读取人物数据和脚本变量，如果脚本里 OnLogin 或登录触发写了大量耗时的操作（遍历背包、全服广播、读外部文本），每个人重连都会卡一下。优化脚本，把不必要的逻辑挪到定时触发里。

登录器自身的验证流程

有些登录器每次启动都要向验证服务器请求一次列表、公告、版本校验，对方响应慢你就跟着卡。换成不依赖外部验证的登录器，或者把验证地址改成自己的本地地址。

五、第四种：服务端每次重启都要重新加载

这部分要先说一句实话：服务端重启后重新加载物品库、技能库、地图、脚本、行会数据，是正常的，不是故障。DBServer 的数据存在 BDE 指向的 dbx 文件里，M2 的地图和脚本存在 Mir200 目录里，它们都是冷读取，没有常驻内存的持久化服务，所以每次都要从头读一遍。1.80 以后的版本地图和脚本多了，启动花一两分钟很常见。

能让它变快的只有几件事：

把服务端放在固态硬盘上，机械盘读几千个脚本文件的差距非常明显。
减少 Mir200 下的无用文件。调试留下的脚本备份、log 文本、旧地图副本，M2 往往会一并扫描。定期清理，备份放到别的目录去。
合并零碎脚本。一个功能拆成几十个小 txt 比写在一个文件里慢，因为每次都要重复打开关闭文件。
关掉不必要的日志输出级别。高频写日志会拖慢启动和运行。
不要频繁重启。日常调试用 @reload 类的GM命令重载脚本和配置，比整服重启快得多。不同引擎命令不一样，查你那一套的说明。

需要警惕的反而是另一种情况：以前启动只要十几秒，现在要几分钟。这通常说明有东西异常了——某个脚本陷入死循环读取、日志文件膨胀到几个G、地图文件损坏导致反复重试、或者杀毒软件在实时扫描每一个被打开的文件。先把杀毒对整个服务端目录做排除，再看 M2 控制台最后停在哪一行，基本就能定位。

六、一个容易被忽略的共因：杀毒和清理软件

这条同时影响上面好几种情况。安全软件会干三件事：拦截 LogServer 和存档目录的写入、把缓存目录当垃圾清掉、实时扫描每一个被引擎打开的配置文件拖慢启动。

一次性处理好：整个 Mirserver 目录和客户端目录都加进排除项；关掉管家的开机自动清理和垃圾清理计划；重启一次电脑让之前的拦截记录失效。做完这一步，莫名其妙的“重新加载”能少掉一半。

七、按顺序走一遍验证流程

先确认现象属于哪一种。看进度条、看人物数据、看服务端控制台，三个信息足够定性。
如果是客户端重下资源：固定缓存路径、加白名单、确认增量更新和版本号生成方式、放行P2P端口、用二进制模式重传资源包。
如果是回档：先救 LogServer，再查存档目录权限和磁盘空间，最后确认关闭顺序和顶号问题。
如果是重连卡：查网关连接释放、优化登录触发脚本、换掉依赖外部验证的登录器。
如果是启动慢：换固态、清冗余文件、降日志级别、用重载命令代替重启。
每一步改完只做一次变动就测试，不要一次改五个地方。

八、长期维护的两个习惯

保留一份能正常运行的干净快照。每次大改之前整目录复制一份，标注日期。出了事直接回滚，比现场排查快。

记一份改动日志。哪天改了缓存路径、哪天换了登录器、哪天盖了补丁，三行字就够。一个月后你绝对记不住，而“我记得上次还好好的”是所有排查中最没用的一句话。

九、关于“无限资源”和修改版的提醒

如果你是因为嫌每次重新加载太麻烦，想去下所谓的一键完整版或无限资源版，这条路省下的时间远不够后面还债。这类包最常见的毛病就是缓存路径写死、索引混乱、组件来自不同发布包，表现出来的恰恰就是反复重下资源和数据对不上。宁可花半天把现有这套环境的配套关系理顺：服务端版本、客户端基础版本、补丁覆盖顺序、登录器配置，四样来自同一套发布，并且每次同步替换。理顺之后，这些问题基本不会再出现。