1. 项目概述为什么我们需要在Unity中引入C#Lua的稳健架构如果你是一个有几年经验的Unity开发者大概率经历过这样的场景游戏上线后发现了一个致命的逻辑Bug或者需要紧急调整某个活动的数值。按照传统的纯C#开发流程你需要修改代码、重新编译、打包、提交平台审核、等待用户更新。这个过程短则几小时长则数天对于一个在线运营的项目来说每一次停服更新都意味着用户流失和收入损失。更头疼的是有时候一个看似简单的修复可能会因为C#代码的强耦合性引发意想不到的连锁反应导致新的Bug。这就是为什么“热更新”或“热修复”能力对于现代游戏尤其是手游变得如此重要。然而当我们谈论热更新时很多讨论往往停留在技术选型的特性对比上哪个方案性能最好哪个方案功能最全哪个方案最“原生”这就像买车只比参数表却忽略了实际驾驶体验和长期维护成本。今天我想从一个更务实的角度出发结合我多次在项目中落地XLua进行热补丁开发的实战经验来聊聊如何超越特性对比真正用C#和Lua构建一个稳健、可维护、长期可靠的Unity项目。稳健意味着它不仅能“热”更要“稳”在频繁的动态更新中不崩溃、不泄露、易于排查问题。我们将深入XLua热补丁的实战细节但更重要的是分享背后的设计哲学、工程实践和那些只有踩过坑才知道的“避雷指南”。2. 核心思路拆解超越“热更新”构建逻辑隔离层2.1 热补丁 vs 全量热更新精准外科手术与器官移植首先我们需要明确一个概念热补丁Hotfix和通常所说的全量热更新Hot Reload是两回事它们解决的痛点不同技术复杂度和风险也不同。全量热更新通常指用Lua或ILRuntime等重写大部分游戏逻辑C#只作为底层引擎接口的封装。更新时可以下载新的Lua脚本资源几乎替换所有游戏行为。这好比给病人更换了大部分器官功能强大且灵活但手术复杂对团队需要熟练掌握另一门语言和架构需要设计良好的C#/Lua交互边界要求极高。热补丁XLua Hotfix它的目标更聚焦——修复已发布的C#代码中的Bug。它通过注入代码的方式在运行时替换掉指定的C#方法实现。这就像一场精准的微创手术只针对病灶处进行修复不动其他健康组织。对于已成型、主体逻辑稳定的项目热补丁是性价比极高的方案。为什么我们选择从热补丁切入因为对于很多中大型项目尤其是上线后的项目推倒重来采用全Lua逻辑成本太高。热补丁允许我们保留经过充分测试的C#核心框架同时获得快速修复线上紧急问题的能力。XLua的热补丁功能正是实现这种“C#主体稳健Lua动态修复”混合架构的关键桥梁。2.2 C#与Lua的职责划分确立不可动摇的边界一个稳健的混合架构始于清晰、严格的职责划分。如果边界模糊C#和Lua代码互相随意调用很快就会变成一团乱麻维护和调试将是噩梦。我们的原则是C#做框架Lua做业务及热补丁。C#稳定层引擎接口封装提供对Unity GameObject、Transform、UI系统、物理系统、资源管理等基础功能的、稳定且高性能的访问接口。核心系统框架网络模块、配置表加载器、音频管理器、事件中心、对象池等。这些系统一旦确定极少变动。基础数据结构与工具类提供Lua中不易实现或性能要求高的通用算法和工具。关键性能路径如战斗中的伤害计算循环、渲染相关的逻辑。这些部分对性能极度敏感应保持在C#侧。Lua动态层游戏业务逻辑角色的技能逻辑、任务系统、活动玩法、商城购买流程等。这些是需求变更最频繁的部分。UI界面控制界面跳转、按钮响应、数据显示刷新。UI是迭代最快的部分之一非常适合用Lua实现。热补丁载体当C#层出现Bug时我们编写的修复代码就是以Lua脚本的形式存在通过XLua注入到对应的C#方法中。配置驱动的行为很多游戏行为可以通过读取配置表如Excel来驱动Lua非常适合解析和执行这类动态逻辑。注意这个边界不是物理上的毕竟通过XLua可以互相调用而是逻辑和设计上的约定。团队必须严格遵守“Lua不直接操作底层Unity对象必须通过C#封装接口”等类似规范否则架构的稳健性无从谈起。2.3 XLua在稳健架构中的核心价值不仅仅是注入XLua提供了[Hotfix]标签来实现热补丁这大家都知道。但从构建稳健项目的角度看它的价值远不止于此非侵入式的桥接通过特性Attribute标记需要热补丁的类和方法对原有C#代码入侵极小。这意味着你的核心C#代码可以保持干净不需要为热更新做大量适配。类型安全的衰减管理C#是强类型Lua是弱类型。XLua在两者之间充当了翻译和缓冲层。它处理了类型转换、函数绑定、委托调用等复杂问题。一个稳健的架构必须正视并管理这种“类型安全衰减”XLua提供了相对完善的解决方案。性能与安全的平衡XLua通过代码生成生成适配代码和缓存机制优化了C#与Lua之间的调用开销。同时它允许你精确控制哪些类、哪些方法可以被Lua访问和修改这为安全提供了基础。3. XLua热补丁实战从配置到注入的完整流程理解了为什么和是什么之后我们进入最关键的“怎么做”。这里我会详细拆解一个完整的、可用于生产环境的热补丁流程并穿插大量实操细节和避坑点。3.1 环境准备与工程配置第一步导入XLua。直接从GitHub仓库下载最新Release版本或通过Unity的Package Manager从Git URL添加。建议使用稳定版本而非开发分支。第二步配置热补丁白名单。这是保障安全的第一步。在Editor目录下创建一个配置文件如HotfixConfig.cs使用[Hotfix]特性来精确指定需要热补丁的类。绝对不要图省事使用[Hotfix]整个程序集。// HotfixConfig.cs 示例 public static class HotfixConfig { [Hotfix] public static ListType by_field new ListType() { typeof(GameManager), typeof(PlayerController), typeof(QuestSystem), // 明确列出需要热补丁的类 }; }第三步生成适配代码。在Unity编辑器中执行XLua提供的菜单项XLua/Generate Code。这个步骤会为白名单中的类生成Lua访问所需的适配代码Wrap文件。每次增删[Hotfix]的类或者修改了被标记类的方法签名后都必须重新生成否则会导致Lua侧调用失败或行为异常。第四步开启热补丁功能。在游戏启动的早期如第一个场景的Awake方法中初始化XLua并启用热补丁。void Start() { LuaEnv luaenv new LuaEnv(); // 执行一些必要的Lua基础脚本 luaenv.DoString(require xLua_hotfix); // ... 其他初始化 }实操心得建议将XLua的初始化封装在一个独立的单例管理器中并确保它在整个应用生命周期内只初始化一次。LuaEnv的创建和销毁成本较高且持有大量资源。3.2 编写你的第一个热补丁Lua脚本假设我们发现PlayerController类的CalculateDamage方法有一个逻辑错误会导致伤害计算溢出。我们需要用Lua写一个修复版本。首先在C#端PlayerController类和方法必须已被[Hotfix]标记。然后我们创建一个Lua脚本文件例如fix_player_damage.lua.txtUnity中通常以.txt作为Lua后缀。-- fix_player_damage.lua xlua.hotfix(CS.PlayerController, CalculateDamage, function(self, baseDamage, multiplier) -- self 对应C#的this -- 原始有Bug的逻辑可能是return baseDamage * multiplier; 如果multiplier为负数或极大值会出问题 -- 修复后的稳健逻辑 local minDamage 1 local maxDamage 999999 local calculated baseDamage * multiplier -- 添加边界检查防止溢出或异常值 if calculated minDamage then calculated minDamage elseif calculated maxDamage then calculated maxDamage end -- 添加日志输出便于线上监控生产环境可去掉或改为条件编译 print(string.format([Hotfix] Damage Calculated: base%d, multiplier%f, result%d, baseDamage, multiplier, calculated)) return calculated end)这段代码的核心是xlua.hotfix函数。它接收三个参数C#类型CS.命名空间.类名、方法名字符串、以及一个Lua函数该函数将成为方法的新实现。3.3 热补丁的加载与管理策略如何让修复脚本在线上生效你不能指望用户手动替换文件。通常有以下几种策略资源包更新将修复脚本fix_player_damage.lua.txt作为AssetBundle打包。当检测到线上Bug时从服务器下载新的AssetBundle加载后执行其中的Lua代码。网络文本加载更轻量级的方式是将Lua脚本内容以纯文本形式存放在服务器。客户端通过HTTP请求获取脚本内容然后使用luaenv.DoString(scriptText)执行。版本化与回滚必须为热补丁脚本设计版本号。客户端本地记录已加载的补丁版本服务器可以指示需要下载的新补丁列表。更重要的是要有回滚机制。如果某个热补丁引入了新问题服务器应能推送一个“空”补丁或旧版补丁调用xlua.hotfix(CS.PlayerController, ‘CalculateDamage’, nil)来移除补丁恢复C#原方法如果原方法没问题或替换为更早的稳定版本。一个简单的热补丁管理器设计public class HotfixManager : MonoBehaviour { private LuaEnv luaEnv; private Dictionarystring, string loadedPatches new Dictionarystring, string(); // patchId - luaScript public void LoadPatchFromWeb(string patchId, string url, Actionbool callback) { StartCoroutine(DownloadScript(url, (scriptText, error) { if (string.IsNullOrEmpty(error)) { try { luaEnv.DoString(scriptText); loadedPatches[patchId] scriptText; SaveToPersistentData(patchId, scriptText); // 本地持久化下次无需下载 callback?.Invoke(true); } catch (System.Exception e) { Debug.LogError($执行热补丁{patchId}失败: {e}); callback?.Invoke(false); } } else { callback?.Invoke(false); } })); } public void RollbackPatch(string patchId) { if (loadedPatches.ContainsKey(patchId)) { // 思路重新加载一个能“抵消”原补丁效果的脚本或直接调用xlua.hotfix移除 // 例如如果知道原方法名可以注入一个调用原C#方法的Lua函数需要更复杂的设计 Debug.LogWarning($回滚热补丁 {patchId}需要具体实现。); } } }4. 深入原理XLua热补丁是如何工作的只知道用还不够理解其原理才能在出问题时快速定位。XLua的热补丁主要利用了C#的委托Delegate和反射Reflection机制但做了一层巧妙的封装。代码生成当你执行Generate Code时XLua会为标记了[Hotfix]的类生成一个“包装器”Wrapper类。这个类包含了原始类所有公共方法对应的Lua桥接方法。方法替换当你调用xlua.hotfix时XLua内部会做以下事情通过反射找到目标C#类型和方法。创建一个Lua函数到C#委托的转换桥接。利用System.Reflection.Emit或在某些平台使用预编译钩子在运行时动态修改方法的执行入口。简单说它把原来方法体开始的指令跳转到了它自己生成的一段“胶水代码”上。这段“胶水代码”负责将C#调用时的参数转换为Lua能理解的数据结构压入Lua栈然后调用你提供的Lua函数最后再将Lua函数的返回值转换回C#类型并返回。性能考量这种动态注入必然有开销。第一次注入方法替换时成本较高。调用时由于多了一层从C#到Lua的跳转和参数转换性能也低于原生C#调用。因此务必遵循“只热补丁真正需要修复的、非性能关键路径的方法”这一原则。对于每帧调用成千上万次的方法应极力避免使用热补丁。5. 构建稳健交互层C#与Lua的通信规范热补丁只是C#与Lua交互的一个场景。在混合编程中大量的日常工作是两者之间的函数调用和数据传递。建立清晰的通信规范是项目稳健的基石。5.1 数据类型的映射与转换理解数据如何在两边传递至关重要C# 类型Lua 中表现注意事项int,float,double,boolnumber,boolean自动转换基本无问题。stringstring自动转换。注意在Lua中大量创建C#字符串可能带来GC压力。class对象userdata在Lua中是一个“用户数据”可以通过obj:Method()调用其方法。生命周期需谨慎管理见下文。struct默认展开为多个返回值或通过[GCOptimize]优化为userdata值类型默认处理方式不同频繁传递建议使用[GCOptimize]标记以减少开销。Array,ListTtable(数组部分)自动转换。修改Lua中的table不会影响原C#集合。DictionaryT,Ktable自动转换。同上修改是单向的。Action,Func委托function可以将Lua函数赋值给C#委托是实现C#回调Lua的关键。重要提示当C#对象传递到Lua后Lua会持有该对象的引用。即使C#侧已经没有引用了只要Lua的userdata还在该C#对象就不会被垃圾回收GC。这可能导致内存泄漏。5.2 C#调用Lua函数事件与回调这是业务逻辑动态化的核心。例如C#的网络模块收到数据后通知Lua层。C#侧public class NetworkManager { // 定义一个C#委托用于Lua回调 [CSharpCallLua] // 必须添加此特性并生成代码 public delegate void OnMessageReceived(string msg); private OnMessageReceived luaMessageHandler; // 提供方法供Lua注册回调 public void RegisterLuaHandler(OnMessageReceived handler) { luaMessageHandler handler; } public void OnReceive(string msg) { luaMessageHandler?.Invoke(msg); } }Lua侧local networkMgr CS.NetworkManager.Instance networkMgr:RegisterLuaHandler(function(msg) print(Lua received message: .. msg) -- 处理网络消息... end)关键点包含[CSharpCallLua]的委托定义必须在生成代码时被处理否则会抛出“尝试调用一个非Lua函数”的异常。5.3 Lua调用C#方法访问引擎与框架这是Lua脚本驱动游戏行为的方式。为了稳健我们不应让Lua直接调用任意C# API。最佳实践设计一个安全的“API网关”。 创建一个专门的C#静态类GameAPI将所有允许Lua访问的功能进行封装和简化。public static class GameAPI { // 1. 对象创建与查找 public static GameObject Find(string path) { return GameObject.Find(path); } public static GameObject InstantiatePrefab(string prefabPath) { /* 封装资源加载和实例化 */ } // 2. UI操作 public static void SetText(UnityEngine.UI.Text uiText, string content) { uiText.text content; } public static void AddButtonListener(UnityEngine.UI.Button button, Action luaCallback) { button.onClick.AddListener(() luaCallback()); } // 3. 事件通知简化版 public static void FireEvent(string eventName, params object[] args) { EventSystem.Instance.Fire(eventName, args); } // 4. 数据存取 public static void SavePlayerData(string key, string value) { PlayerPrefs.SetString(key, value); } }在Lua中通过CS.GameAPI来调用这些方法。这样做的好处是控制暴露面Lua只能做你允许它做的事情。简化接口对复杂的Unity API进行二次封装提供更符合脚本语言的简洁接口。集中错误处理可以在GameAPI的方法内部添加统一的Try-Catch和日志防止Lua脚本的错误直接导致Unity崩溃。性能优化可以对高频调用进行缓存或优化。6. 内存管理避免混合开发中的“内存泄漏”混合开发中最隐蔽的坑就是内存管理。C#有GCLua也有自己的GC两者通过XLua交互引用关系变得复杂。常见内存泄漏场景与解决方案C#对象在Lua中永不释放场景将一个C#的Texture2D对象传递给Lua使用Lua一直持有其userdata。即使C#逻辑里已经不再需要这个纹理它也无法被GC回收。解决主动释放在Lua中明确置nil。当确定不再需要该对象时执行myTexture nil并可能触发Lua的GCcollectgarbage()。使用弱引用XLua支持LuaTable的弱引用。但对于C#对象的userdata其生命周期主要由C#侧和Lua对该userdata的引用共同决定。更有效的方法是设计资源管理策略例如所有通过GameAPI获取的资源都由一个中央资源管理器管理生命周期Lua只持有资源ID而非直接对象。Lua函数注册到C#事件未注销场景在Lua中为一个UI按钮的onClick事件添加了监听函数。界面关闭时如果只是销毁了GameObject但没移除监听那么Lua函数、其所属的Lua环境闭包以及它可能引用的C#对象都无法被释放。解决必须配对注册与注销。为每个UI界面或模块提供明确的OnDestroy或Dispose函数在其中清理所有注册到C#事件的Lua回调。local function onButtonClick() -- do something end function MyView:Start() CS.GameAPI.AddButtonListener(self.button, onButtonClick) end function MyView:OnDestroy() -- 关键移除监听这里需要GameAPI提供对应的Remove方法。 CS.GameAPI.RemoveButtonListener(self.button, onButtonClick) self.button nil onButtonClick nil -- 帮助Lua GC endLua表Table中持有大量C#对象引用场景一个Lua的全局表AllUnits保存了战场上所有单位的C#对象引用。单位死亡后只是从C#的战场管理器移除了但Lua表里还留着。解决定期清理或使用弱引用表。Lua支持弱引用表setmetatable({}, {__mode “v”})其值value是弱引用不会阻止对象被GC。但注意键key如果是userdata也需要设置为弱引用__mode “kv”。内存排查工具Lua侧使用collectgarbage(“count”)查看Lua内存使用单位是KB。在关键节点前后打印观察内存增长。C#侧使用Unity Profiler的Memory模块观察Lua相关的内存分配以及疑似泄漏的C#对象实例数量是否只增不减。XLua工具XLua提供了xlua.meminfo函数可以打印更详细的Lua内存信息。7. 调试与错误处理让问题无处遁形混合开发的调试比纯C#复杂。错误可能发生在C#、Lua或者两者的交互边界。7.1 Lua错误处理Lua代码中的语法错误或运行时错误如果不捕获会导致整个DoString或函数调用失败错误信息可能不直观。全局错误处理可以设置Lua环境的错误处理函数。-- 在初始化Lua环境后 xlua.util.set_error_func(function (msg) -- 将错误信息发送到服务器或本地日志文件 CS.UnityEngine.Debug.LogError([LUA ERROR] .. msg) -- 打印调用栈 print(debug.traceback()) end)pcall保护调用在C#调用可能出错的Lua函数时使用pcall。// C# 调用 Lua 函数 LuaFunction func luaEnv.Global.GetLuaFunction(someLuaFunction); object[] result; bool success func.Call(parameters, out result); if (!success) { Debug.LogError(Lua function call failed: result[0]); // result[0] 是错误信息 }7.2 C#与Lua交互错误这类错误通常由类型不匹配或未生成适配代码引起。“attempt to call a nil value”通常是因为Lua中调用的C#方法名写错或者对应的C#类/方法没有添加[LuaCallCSharp]特性并生成代码。“invalid arguments to method”参数数量或类型不匹配。检查Lua调用时传入的参数是否符合C#方法签名。“XLua: No matching overload found”同样是参数匹配问题可能发生在有多个重载方法时。调试技巧日志埋点在关键的C# API网关方法和Lua模块入口处添加详细的日志记录参数和返回值。使用IDE调试可以配置VSCode或IntelliJ IDEA等IDE使用MobDebug等插件进行Lua代码的远程断点调试。XLua的print重定向将Lua的print函数重定向到Unity的Debug.Log方便在Unity Editor和某些平台的开发日志中查看。luaEnv.Global.Set(print, new Actionstring(Debug.Log));7.3 热补丁特有的调试问题补丁未生效首先检查目标类和方法是否正确添加了[Hotfix]并重新生成了代码。其次检查热补丁Lua脚本是否被正确加载和执行没有语法错误。可以在热补丁脚本的第一行加一个print(“Hotfix loaded!”)来验证。补丁导致新Bug热补丁代码运行在Lua环境但操作的是C#对象。务必注意线程安全问题。如果热补丁修改了共享状态如静态变量而原C#方法或其他线程也在访问就可能引发竞态条件。热补丁的逻辑应尽量保持“无状态”和“幂等”。8. 性能优化指南让混合架构跑得更快性能是稳健性的重要组成部分。一个总是卡顿的项目谈不上稳健。减少C#与Lua的跨界调用这是最大的性能开销来源。一次跨界调用比一次纯C#内部调用慢数十甚至上百倍。批量化操作避免在循环中进行跨界调用。例如不要在一个for循环里每次调用CS.GameAPI.SetText来设置UI文本。应该先在Lua侧拼接好所有字符串或者通过一个封装好的C#方法一次性传入所有数据。缓存引用对于需要频繁访问的C#对象如GameObject、Component应该在Lua侧缓存其引用而不是每次通过CS.GameObject.Find去查找。优化数据类型传递避免频繁传递大的string或复杂的table。对于需要大量交换的数据考虑在C#侧设计高效的数据结构Lua通过ID或索引来访问。对于值类型如Vector3如果频繁传递使用[GCOptimize]标记该结构体XLua会生成优化代码避免每次传递都产生装箱拆箱开销。Lua代码本身的性能局部变量Lua中访问局部变量比全局变量快得多。在性能关键的函数内将频繁访问的全局函数或模块赋值给局部变量。local Vector3 CS.UnityEngine.Vector3 -- 缓存到局部变量 local sqrt math.sqrt for i1,1000 do local magnitude sqrt(Vector3.Dot(vec, vec)) -- 使用局部变量 end避免在热路径创建临时表在每帧执行的Update逻辑中避免使用{}创建新的table这会给Lua GC带来压力。可以尝试复用table。对象池无论是C#的GameObject还是Lua中表示复杂业务逻辑的对象都应考虑使用对象池来避免频繁创建和销毁带来的GC开销。Profiling永远不要凭感觉优化。使用Unity Profiler和XLua提供的性能分析工具如xlua.profile来定位真正的性能瓶颈。你可能会发现最大的开销并不是你想象的那部分代码。9. 工程化与团队协作让混合开发可持续个人项目可以随意但团队项目必须有规范。否则混合架构的优势会迅速被混乱的代码所抵消。代码组织规范目录结构明确划分C#脚本和Lua脚本的目录。例如/Scripts/CSharp/ (框架、系统、引擎封装) /Scripts/Lua/ (业务逻辑、UI控制、热补丁) /Logic/ (游戏逻辑模块) /UI/ (界面控制) /Hotfix/ (热补丁脚本) /Common/ (Lua公共库)命名约定规定C#暴露给Lua的API命名风格如使用PascalCaseLua模块和变量的命名风格如使用snake_case。模块化与通信鼓励将Lua代码组织成模块Module使用require加载避免全局变量污染。设计一个轻量级的、基于字符串或枚举的事件系统用于C#与Lua之间、Lua模块之间的松耦合通信。避免模块间直接函数调用形成网状依赖。构建与部署流程自动化代码生成将XLua/Generate Code和XLua/Copy Files等步骤集成到CI/CD流水线中确保每次构建前适配代码都是最新的。Lua代码编译与加密发布时可以使用luac将Lua源码编译成字节码增加一定的反编译难度。同时可以对字节码进行自定义的加密处理。XLua支持加载字节码。补丁版本管理建立数据库或配置文件管理所有发布的热补丁版本、对应的Bug描述、影响范围以及回滚策略。文档与知识沉淀维护一个内部的“XLua/C#交互手册”记录常见的API用法、坑点、最佳实践。对新成员进行混合开发规范的培训。10. 常见问题排查速查表最后我将项目中遇到的一些典型问题及解决方案浓缩成下表供你快速查阅问题现象可能原因排查步骤与解决方案热补丁不生效1. 目标类/方法未加[Hotfix]。2. 未执行Generate Code。3. Lua脚本未成功加载或执行有语法错误。4. 方法签名不匹配重载问题。1. 检查HotfixConfig配置。2. 执行生成并确认Wrap文件存在。3. 在Lua脚本开头加print调试检查加载流程。4. 使用xlua.hotfix时确认方法名和参数数量完全正确。调用C#方法报nil错误1. 类名或方法名拼写错误。2. 该方法不是public。3. 该类未加[LuaCallCSharp]或未生成代码。4. 在iOS等AOT平台未提前静态注册。1. 仔细检查拼写注意命名空间。2. 确认方法访问权限。3. 添加特性并生成代码。4. 对于AOT平台确保在静态列表中添加了该类型。内存持续增长1. Lua中持有了C#对象未释放。2. C#事件注册了Lua回调未注销。3. Lua表频繁创建未回收。1. 使用Profiler查看Lua内存和C#对象实例数。2. 检查UI、事件监听等处的注册/注销是否成对。3. 在Lua中对大型临时表置nil或使用对象池。性能突然下降1. 某帧内发生了大量C#-Lua跨界调用。2. Lua代码中存在低效算法如大表遍历。3. 频繁创建Unity对象如GameObject, Texture。1. 使用Profiler的CPU模块查看Lua调用堆栈。2. 优化Lua算法缓存跨界调用结果。3. 实现对象池。Android/iOS上崩溃1. 平台相关的原生代码调用错误。2. 热补丁修改了AOT不支持的代码路径。3. 内存不足。1. 确保所有平台相关的C# API都经过充分测试。2. 在AOT平台热补丁限制更多需仔细测试。3. 加强内存监控和日志分析崩溃日志。Lua报错信息不清晰错误被吞没未正确捕获或打印。设置全局的Lua错误处理函数set_error_func并在C#调用Lua时使用pcall保护。