Lua 热更新是指在不重新编译、不重新发版的前提下，于运行时替换已加载的 Lua 脚本代码或函数实现的技术。它利用 Lua 动态加载与 package.loaded 缓存机制，让游戏或服务器可以在线修复 Bug、更新玩法，是手游和服务端运营的关键基础设施。
为什么需要热更新
理解热更新之前，先看它解决的痛点：
- 发包审核周期长：iOS App Store 的审核通常需要一到数天，安卓各渠道也要走各自的上架流程。一个影响玩家体验的恶性 Bug，如果只能等下一个安装包，损失可能已经造成。
- 运营节奏快：手游的活动、数值、玩法需要按周甚至按天迭代，每次都发整包既不现实也伤害留存（用户不愿意频繁更新几百 MB 的安装包）。
- 服务端不能停：游戏服务器停机维护意味着全体玩家掉线，能在线修复逻辑就不停服。
Lua 恰好是解决这些痛点的理想载体：解释执行、代码即数据、体积小易分发，运行时替换脚本不需要重启进程。这也是游戏行业普遍选择 Lua 的核心原因之一。
核心原理：require 与 package.loaded
Lua 的模块系统（详见 Lua 模块与包）建立在 require 函数之上。第一次 require "foo" 时，Lua 会查找并执行 foo.lua，把返回值缓存进 package.loaded["foo"]；之后再 require "foo" 直接返回缓存，不会重新执行文件。
热更新的第一个关键操作因此显而易见：把缓存置空，再重新 require，就能加载新版本的模块。
-- 热重载一个模块的最小实现
local function reload(modname)
-- 清除缓存，下次 require 会重新执行模块文件
package.loaded[modname] = nil
local ok, mod = pcall(require, modname)
if not ok then
-- 新代码有语法或运行时错误，保留现场并上报
print("热更失败:", modname, mod)
return nil
end
return mod
end
-- 使用示例：逻辑版本从 v1 切到 v2
local logic = reload("game.battle_logic")
if logic then
logic.on_battle_start()
end
实际工程中还会配合版本清单（manifest）与差异下载：客户端启动时拉取远端版本号，对比本地，只下载变化的脚本文件，写入可读写的持久化目录（Lua 的 package.path 优先指向该目录），再触发 reload。
两种热更粒度
整脚本替换
最简单的方式：整个模块文件替换后重新 require。优点是实现简单、逻辑清晰；缺点是模块内的运行时状态会丢失——新模块是全新执行的，旧模块里的局部变量、注册过的回调引用并不会自动迁移。适用于无状态或状态易重建的逻辑模块。
函数级补丁
更精细的做法：不重新加载整个模块，只把新函数替换进旧的模块表。这样模块表本身不变，所有持有旧模块引用的代码立刻用上新逻辑，模块内的 upvalue 状态也得以保留。
-- 假设旧模块已经加载
local battle = require("game.battle_logic")
-- 服务器下发的补丁代码（字符串形式）
local patch_code = [[
return function(old_calc_damage)
return function(attacker, defender)
-- 修复：伤害下限从 0 改为 1
local dmg = old_calc_damage(attacker, defender)
return math.max(dmg, 1)
end
end
]]
-- 加载补丁并替换表中的函数字段
local patch = load(patch_code)()
battle.calc_damage = patch(battle.calc_damage)
这种「替换表字段」的手法还能包装旧函数实现 AOP 式修复，是线上紧急止血最常用的技巧。补丁代码还可以借助元表与元方法 拦截对象行为，做更深层的修复。
业界方案
不同平台衍生出不同的热更体系，原理各不相同：
- xLua（Hotfix 注入）：Unity 项目的主力方案。日常用 C# 开发保证性能，运行期发现问题时，xLua 通过 IL 层注入，把 C# 方法的入口转发到 Lua 函数，实现「C# 方法打 Lua 补丁」。开发期无感知，补丁期下发 Lua 脚本，下个整包再把修复固化回 C#。完整的接入与实战流程见 Unity xLua 实战指南。
- toLua / sLua：更早一代的 Unity Lua 绑定方案，思路是把尽可能多的业务直接写在 Lua 层，Lua 代码天然可热更，C# 层只做引擎桥接。
- ILRuntime：不依赖 Lua，直接在 Unity 内跑一个 IL 解释器执行 C# 程序集，适合团队纯 C# 技术栈的项目。
- Skynet snax 热更：服务端场景。Skynet 的 snax 服务框架支持
snax.hotfix，把服务的消息处理函数替换为新版本，同时保留服务状态，实现不停机更新业务逻辑。
定性地区分：客户端方案（xLua/toLua）解决「无法重新编译的宿主代码如何修」，服务端方案（Skynet）解决「不能停机的服务如何换逻辑」，而纯 Lua 层的模块重载则是两者共用的基础能力。
工程实践注意事项
upvalue 与闭包导致的状态残留
函数级补丁最大的坑是 upvalue：旧函数引用的局部变量被闭包持有，替换了表里的函数字段，并不代表所有地方都换上了新函数——之前缓存了旧函数引用的代码（例如事件监听表、定时器回调）依然在跑旧逻辑。热更框架需要提供统一的函数查找入口，或约定所有调用都经过模块表间接寻址。
元表与类实例的迁移
如果用 table + metatable 实现了类（见 Lua 面向对象编程），热更类方法后，已存在的实例的元表仍指向旧的类表。常见做法是让实例的 __index 指向一个稳定的类表对象，热更时只更新类表里的方法字段，实例自动生效；或者提供 migrate 钩子逐个修复存量对象。
版本管理与回滚
热更代码必须像正式版本一样管理：每个补丁有版本号、依赖的整包版本、灰度发布策略。新补丁上线后一旦发现更坏的问题，要能秒级回滚到上一版本——通常做法是保留最近 N 个版本的补丁包，客户端校验失败或崩溃率上升时自动回退。
安全校验
补丁代码是直接注入进程的 Lua 代码，必须防止篡改：下发渠道走 HTTPS 只是传输层保护，还应给补丁包做签名（如 RSA 签名校验），客户端内置公钥验签通过后才允许加载，避免中间人注入恶意脚本。同时热更内容应遵守平台规则——修复 Bug、调整数值一般没有问题，但借热更绕过审核上线全新付费功能有被拒审或下架的风险。
常见问题（FAQ）
热更新会被苹果审核拒绝吗？
苹果禁止的是「通过热更显著改变 App 的核心功能、绕过审核上线新特性」。用 Lua 热更修复 Bug、调整数值、更新活动内容是行业普遍做法，只要不突破这条边界、不进行代码混淆对抗，一般不会因此被拒。关键是热更内容要克制，别把它当成绕开审核的通道。
热更和增量更新有什么区别？
热更是运行期替换正在执行的代码逻辑，进程不重启、玩家不重新下载安装包；增量更新（差分更新）是减少安装包或资源包的下载体积，更新后通常仍需要重启生效。两者解决的是不同问题，实际项目里往往同时存在。
Lua 热更有什么风险？
主要有三类：状态一致性风险（旧闭包、旧实例残留导致新旧逻辑混跑）、安全风险（补丁被篡改注入恶意代码，需签名校验）、质量风险（热更绕过了完整的测试发版流程，补丁本身可能引入新 Bug，需要灰度与回滚机制兜底）。
函数级补丁和整脚本重载该选哪个？
无状态的纯逻辑模块用整脚本重载，简单可靠；有运行状态、被大量回调引用的模块用函数级补丁，避免状态丢失。成熟项目通常两者结合：常规更新走模块重载，紧急止血走函数补丁。
相关阅读
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。