HGE 的热重载：改完脚本哪些立刻生效、哪些必须重启

热重载是开区之后最常用的操作。改一个 NPC 的对话，不想重启服务端影响在线；改一个数值，希望立刻生效。但热重载不是万能的，改错了地方，改了等于没改。

一、热重载能省什么

省的是重启的时间，和在线的中断。一次重启少则几十秒，多则几分钟，开区当晚重启一次，玩家就会抱怨。

但热重载省不了“验证”。改完一定要实际去看一眼，不能假设它生效了。

所以热重载的正确用法是：能热更的用热更，不能的把改动攒到一起，在一个低峰时段统一重启。

二、立刻生效的：NPC 脚本和对话

NPC 脚本是热重载支持得最好的部分。改完对话、加一个按钮，重新加载脚本就能看到效果。

这类改动风险也最低，因为只影响对话逻辑，不影响战斗计算。

但要注意：正在和这个 NPC 对话的玩家，看到的可能还是旧内容。让玩家关掉对话框再打开，就能看到新的。

还有一个细节：脚本文件的编码。热重载读取的是文件，编码不对会读成乱码，看起来像热重载失败。

三、需要重新加载的：物品表和怪物表

物品属性、怪物属性这类配置，通常需要显式触发一次重载，而不是自动生效。

重载之后，已经在场景里的怪物可能还是旧属性，新刷出来的才是新的。要验证，得等一轮刷新。

物品表重载的风险更大。玩家背包里已有的物品，属性可能不会立刻更新，要等下次登录或者重新获取。

这类改动建议在低峰做，并且提前公告，避免玩家发现“我的装备属性怎么变了一半”。

四、必须重启的：引擎参数、端口、数据库

三类必须重启：引擎核心参数、网络端口、数据库连接。

引擎核心参数改了不重启，往往是部分生效，表现出来就是“有时候对有时候不对”，最难查。

端口改了不重启，服务端还在旧端口监听，玩家连不上，而你以为改好了。

数据库连接改了不重启，引擎还连着旧的库，读到的数据全是旧的。这一条最危险，因为表面一切正常。

遇到这三类，不要犹豫，直接安排重启，并提前公告。

五、判断方法：改一个值看反应

不确定某个配置能不能热更，最土的办法是改一个显眼的值，然后实际去看。

比如把一个 NPC 的对话改一个字，重新加载，看游戏里变没变。变了说明支持热更，没变说明要重启。

这个方法花两分钟，能省掉后面半小时的困惑。每个版本第一次接触时，把关键配置都这样试一遍，记下来。

试出来的结果整理成一张表，下次直接查，不用再试。

六、热重载的风险：半更新状态

热重载最大的风险不是不生效，是只生效一半。

比如你改了物品表的两个字段，一个生效一个没生效，玩家看到的装备就是矛盾的：攻击变了，防御没变。

还有一种情况是多台服务器。你在一台上热更了，另一台没更，玩家在不同区看到不同的结果，投诉会集中爆发。

所以热更要成批做，并且确认所有节点都执行了。只更一台，比不更更糟。

七、一个安全的操作流程

第一步，在测试服改完并验证。

第二步，确认这个改动属于哪一类：立刻生效、需要重载、必须重启。

第三步，如果是前两类，选一个在线低谷，公告后执行。

第四步，执行完立刻用一个测试号验证，不要等玩家反馈。

第五步，记录这次改动的内容和时间，方便出问题时回溯。

五步里最容易被跳过的是第四步。改完不看，等于没改。

八、开区当天建议

开区当天只做“立刻生效”类的热更，其他改动一律攒着。

当天任何需要重启的改动，都要评估影响：现在重启会掉多少人，能不能等到凌晨。

还有一条：开区当天不要做“优化性”的改动。只修明显的问题，不改没坏的东西。改动越多，风险越大。

热重载是工具，不是保险。真正让开区顺利的，是改动之前的判断。

九、把结论写成一张表

每个版本第一次上手，建议花半天把常用配置项过一遍，做成一张三列的表：配置项、生效方式、验证方法。

配置项写具体名字，不要写“物品相关”这种模糊描述。生效方式只填三个值之一：立刻生效、需要重载、必须重启。验证方法写一句能执行的话，比如“改一个 NPC 对话，重载后进游戏点开看”。

这张表的价值在交接。换了人维护，看一眼表就知道哪些能动、哪些不能动，不用再拿线上环境去试。

表还要跟着版本走。引擎升级之后，原本能热更的配置可能变成必须重启，不更新表就会照着旧结论踩坑。

另外把每次热更都记一笔：时间、改了什么、谁改的、验证结果。出事时这份记录比任何排查都省时间，至少能立刻排除“是不是刚才那次改动”。

看起来是额外工作，但做过两三个区之后，这张表和这份记录会是整个维护流程里最省事的东西。