企业官网建设流程全解析

1. 项目概述：为什么升级 xLua 版本不是“点个按钮”就完事的事

Unity 项目里用 xLua 做热更或脚本解耦，几乎是国内中大型手游团队的标配方案。但很多人第一次真正面对“升级 xLua 版本”这个任务时，才发现它根本不是 GitHub 上 clone 新 tag、替换 Plugins 文件夹那么简单——你刚把 xLua 2.3.0 换成 2.4.0，Unity 编辑器里跑得飞起，一导出 Android 包就闪退；iOS 构建通过了，但运行时 Lua 调用 C# 方法直接报attempt to call a nil value；WebGL 加载 Lua 脚本卡在xlua.init()，控制台只有一行TypeError: Cannot read property 'luaL_newstate' of undefined……这些不是玄学，是实实在在的平台差异、ABI 兼容性、编译链路断裂和符号链接错位导致的硬伤。

我做过 7 个 Unity 项目（从 Unity 2018.4 到 2022.3），其中 5 个深度依赖 xLua 实现热更新和逻辑热插拔。每次升级 xLua，我都得花至少 3 天时间重新梳理整个构建流水线：不是写代码，而是像一个嵌入式工程师一样，盯着.so、.dll、.a、.bc这些二进制文件的生成路径、导出符号表、架构 ABI 和链接器参数。xLua 本身不跨平台，它只是桥接层；真正决定你能不能跑起来的，是你本地的 NDK、Xcode、IL2CPP 编译器、WebAssembly 工具链，以及它们之间那条极其脆弱的“信任链”。

核心关键词Unity、xLua、编译、链接库、平台，每一个词背后都是一道关卡：Unity 决定你用什么后端（Mono/IL2CPP）、什么构建管线（Legacy/URP/HDRP）；xLua 决定你用哪个 Lua 解释器（Lua 5.3/LuaJIT）、是否启用 GC 优化、是否支持泛型反射；编译过程决定你能否生成符合目标平台 ABI 的原生库；链接库决定你能否在运行时正确加载、符号解析成功；而平台——Android/iOS/WebGL/Windows/macOS/Standalone Linux——每一种都要求你提供完全不同的二进制形态、符号导出规则、甚至内存对齐方式。

这不是一个“技术选型”问题，而是一个“工程交付可靠性”问题。你升级 xLua 的目的，可能是为了修复某个 Lua 字符串处理的崩溃 bug，也可能是为了接入新的协程调度机制，但如果你没把不同平台的链接库编译流程彻底理清，那这个“升级”带来的风险，远大于收益。下面我就以一个真实项目（Unity 2021.3.26f1 + xLua 2.4.1 → 2.4.4）为蓝本，把整套升级+多平台编译的实操细节、原理陷阱、避坑经验，掰开揉碎讲清楚。

2. 升级前必须搞懂的底层逻辑：xLua 的三重编译层级与平台适配本质

很多开发者误以为 xLua 就是个 C# 插件包，升级就是换 DLL。这是最危险的认知偏差。xLua 实际上由三个物理上分离、逻辑上强耦合的模块组成，每一层都对应不同的编译行为和平台约束：

2.1 C# 层：Unity 插件主体（Managed Code）

这是你日常接触最多的部分——XLua.dll、XLuaGenarated.cs、LuaEnv.cs等 C# 脚本。它负责：

• 在 Unity 运行时创建 LuaState、管理 Lua 栈、封装 C# 对象到 Lua 表；
• 提供[CSharpCallLua]、[LuaCallCSharp]等特性，驱动代码生成器；
• 与 Unity 的 MonoBehaviour 生命周期、主线程调度、GC 回收机制深度绑定。

关键事实：C# 层本身是跨平台的（.NET Standard 2.0），但它对底层原生库的调用方式，受 Unity 后端（Mono/IL2CPP）严格制约。比如在 IL2CPP 下，所有 P/Invoke 必须声明为DllImport("xlua")，且xlua这个名字必须与你最终生成的原生库文件名（不含扩展名）完全一致；而在 Mono 下，它可能允许你写DllImport("xlua.dll")或DllImport("libxlua.so")。这就是为什么你升级 xLua 后，编辑器里能跑，真机上挂——C# 层没变，但 P/Invoke 的符号查找逻辑变了。

2.2 C/C++ 层：原生核心（Native Code）

这才是 xLua 的“心脏”，位于Assets/Plugins/xLua/Source目录下，包含：

• xlua.c：Lua C API 的封装，处理lua_pushcfunction、lua_getfield等核心调用；
• tolua.c：类型转换引擎，负责int↔number、string↔char*、C# object↔userdata的双向序列化；
• luajit/src/（若启用 LuaJIT）：高度优化的 JIT 编译器，其汇编指令集与 CPU 架构强绑定；
• unity_support.c：Unity 特有胶水代码，处理UnityObject引用计数、GameObject生命周期同步等。

关键事实：这一层必须为每个目标平台单独编译，且输出格式、ABI、符号导出规则完全不同：

• Android：需编译为libxlua.so（ARMv7/AARCH64），使用 NDK r21e+，APP_ABI := armeabi-v7a arm64-v8a，链接libil2cpp.so和libunity.so；
• iOS：需编译为libxlua.a（静态库），Xcode 13+，VALID_ARCHS = arm64 arm64e，必须开启Enable Bitcode = NO（xLua 不支持 Bitcode）；
• WebGL：需编译为xlua.bc（LLVM bitcode），Emscripten 2.0.2+，-s STANDALONE_WASM=0 -s EXPORTED_FUNCTIONS="['_luaL_newstate', '_xlua_get_type']"，导出函数名必须带下划线前缀；
• Windows：xlua.dll（动态库），Visual Studio 2019+，/MT静态链接 CRT，避免运行时依赖冲突；
• macOS：libxlua.dylib（动态库），Xcode 13+，-undefined dynamic_lookup允许运行时符号延迟绑定。

提示：xLua 官方提供的预编译库（如Plugins/Android/libxlua.so）仅适用于特定 NDK 版本和 Unity IL2CPP 版本。一旦你的 Unity 升级了 IL2CPP 编译器（比如从 2021.3.10f1 升到 2021.3.26f1），其libil2cpp.so的符号表结构可能已变更，旧版libxlua.so就会因符号未找到而加载失败。

2.3 代码生成层：C# <-> Lua 绑定桥（Generated Code）

当你在 C# 类上加[CSharpCallLua]，xLua 的Genarator工具会在Assets/Plugins/xLua/Gen/下生成一堆*.cs文件，例如UnityEngine_GameObject_Binding.cs。这些文件本质是“胶水函数”，把 C# 方法调用翻译成 Lua C API 调用序列。

关键事实：生成代码的正确性，取决于xLua.dll的元数据读取能力和Generator.exe的 .NET 运行时版本。xLua 2.4.0 使用 .NET Framework 4.7.2 编译Generator.exe，而 2.4.4 可能已升级到 .NET 6.0。如果你的 Windows 系统没装对应 .NET 运行时，Generator就会静默失败，不生成任何绑定文件，导致运行时LuaEnv.Global.GetInPath("UnityEngine.GameObject")返回null，后续调用全部崩盘。

这三层不是并列关系，而是严格的依赖链：C# 层调用 C 层函数 → C 层调用 Unity 原生 API → Unity 原生 API 最终调用操作系统接口。任何一层的 ABI 不匹配、符号缺失、调用约定错误，都会导致整个链条断裂。所以，“升级 xLua 版本”本质上是在重构这条链路上所有环节的兼容性验证。

3. 多平台链接库编译全流程：从源码到可部署二进制的每一步实操

升级 xLua 后，你不能直接用官方预编译包。必须基于新版本源码，为每个目标平台重新编译链接库。下面是我实际操作中验证过的完整流程，以 xLua 2.4.4 为例（GitHub Release Tag），适配 Unity 2021.3.26f1。

3.1 环境准备：精准匹配工具链版本（比写代码还重要）

xLua 对工具链版本极其敏感。我曾因 NDK 版本差一个小版本（r21d vs r21e），导致 Android 包在小米 12 上闪退，日志只显示signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)。以下是经过千次构建验证的黄金组合：

注意：Unity 2021.3 默认使用 IL2CPP 2.0.12，它要求 NDK r21e 的libc++_shared.so版本必须是21.4.7075529。如果你用 r23b，libc++_shared.so版本是23.1.7529575，两者 ABI 不兼容，会导致dlopen失败。务必用strings libxlua.so \| grep "libc++"验证。

3.2 Android 平台：SO 库编译与符号检查（最易踩坑）

步骤 1：修改build_android.sh脚本

xLua 源码根目录下的build_android.sh是编译入口。你需要做三处关键修改：

# 原始脚本可能指向旧 NDK export NDK_HOME="/Users/yourname/Library/Android/sdk/ndk/21.4.7075529" # 必须精确到 patch version # 添加 ARM64 支持（Unity 2021.3 默认启用） APP_ABI="armeabi-v7a arm64-v8a" # 关键！强制链接 Unity IL2CPP 符号 LDFLAGS="-L$NDK_HOME/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a -L$NDK_HOME/sources/cxx-stl/llvm-libc++/libs/arm64-v8a -lc++_shared"

步骤 2：编译并验证 SO 文件

chmod +x build_android.sh ./build_android.sh # 编译完成后，检查生成的 so 是否包含必需符号 # 进入 Assets/Plugins/Android/ arm-linux-androideabi-readelf -Ws libxlua.so \| grep "luaL_newstate\|xlua_get_type" # 正确输出应类似： # 72: 0000000000001234 20 FUNC GLOBAL DEFAULT 1 luaL_newstate # 105: 0000000000005678 16 FUNC GLOBAL DEFAULT 1 xlua_get_type

如果grep无输出，说明符号未导出——检查xlua.c开头是否有#define XLUA_EXPORT __attribute__((visibility("default")))，且函数声明前是否加了XLUA_EXPORT。

步骤 3：Unity 中的路径与加载验证

将生成的libxlua.so放入Assets/Plugins/Android/，确保：

• 文件 Inspector 中Platform设置为Android；
• CPU设置为ARMv7和ARM64（勾选两项）；
• Load Type为Default（不是Don't Process）。

在 Unity 编辑器中新建测试脚本：

public class XluaTest : MonoBehaviour { void Start() { try { var env = new LuaEnv(); Debug.Log("xLua init success"); env.DoString("print('Hello from Lua')"); env.Dispose(); } catch (System.Exception e) { Debug.LogError("xLua init failed: " + e); } } }

实测心得：Android 真机调试时，务必用adb logcat | grep -i "xlua\|lua\|il2cpp"过滤日志。常见错误dlopen failed: library \"libil2cpp.so\" not found表明你的libxlua.so没有正确链接libil2cpp.so，需在Android.mk中添加LOCAL_SHARED_LIBRARIES := il2cpp。

3.3 iOS 平台：静态库编译与 Bitcode 处理（苹果审核红线）

iOS 是最严格的平台。xLua 官方明确不支持 Bitcode，而 Unity 2021.3 默认开启 Bitcode（Xcode 项目设置中Enable Bitcode = YES）。如果你不手动关闭，Archive 时会报错bitcode bundle could not be generated because '/path/to/libxlua.a' was not compiled with bitcode。

步骤 1：编译静态库

xLua 源码中build_ios.sh脚本需调整：

# 指向 Xcode 13.4.1 的 SDK export SDKROOT="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.5.sdk" # 关键！禁用 Bitcode 编译 CFLAGS="-fembed-bitcode-marker -miphoneos-version-min=10.0 -arch arm64 -isysroot $SDKROOT" LDFLAGS="-arch arm64 -isysroot $SDKROOT -dead_strip"

运行./build_ios.sh，生成libxlua.a。

步骤 2：Unity 导出 Xcode 项目后的关键修改

Unity 导出 Xcode 项目后，打开Unity-iPhone.xcworkspace，执行三步操作：

1. 在Build Settings中搜索Enable Bitcode，设为NO；
2. 搜索Other Linker Flags，添加-ObjC -all_load（确保 xLua 的 category 被加载）；
3. 将libxlua.a拖入Frameworks分组，勾选Copy items if needed，并在Build Phases > Link Binary With Libraries中确认已添加。

步骤 3：符号冲突排查（iOS 特有）

iOS 上常见duplicate symbol _luaL_newstate in ...错误。这是因为 Unity 自带的liblua.a（用于某些内部功能）和你的libxlua.a都定义了同名符号。解决方案：

• 修改xlua.c，将所有luaL_newstate替换为xlua_L_newstate；
• 在build_ios.sh的CFLAGS中添加-DluaL_newstate=xlua_L_newstate；
• 重新编译libxlua.a。

提示：Unity 2021.3 的liblua.a位于Unity.app/Contents/PlaybackEngines/iOSSupport/，你无法修改它，只能改 xLua 的符号名。这是 iOS 平台升级 xLua 的必经之路。

3.4 WebGL 平台：Bitcode 到 WASM 的转换（最容易被忽略的环节）

WebGL 的难点不在编译，而在链接。xLua 2.4.4 之前版本默认导出函数名不带下划线，而 Emscripten 2.0+ 要求所有导出函数必须以下划线开头（_luaL_newstate），否则 JS 侧调用时Module._luaL_newstate为undefined。

步骤 1：修改build_webgl.sh

# 关键！添加导出函数声明 EMCC_FLAGS="-s EXPORTED_FUNCTIONS=\"['_luaL_newstate','_xlua_get_type','_xlua_push_csharp_object']\" \ -s EXPORTED_RUNTIME_METHODS=\"['ccall','cwrap']\" \ -s STANDALONE_WASM=0 \ -s ALLOW_MEMORY_GROWTH=1"

步骤 2：编译并提取 WASM

./build_webgl.sh # 生成 xlua.js 和 xlua.wasm # 但 Unity 需要的是 .bc 文件（bitcode），不是 .wasm # 所以要反向提取：emcc xlua.bc -o xlua.js --bind # 实际上，xLua 源码的 build_webgl.sh 会生成 xlua.bc，直接用它

将生成的xlua.bc放入Assets/Plugins/WebGL/，Unity 会在构建时自动将其链接进WebGL.framework.js。

步骤 3：JS 层调用验证

在浏览器开发者工具中，执行：

// 确保 Module 已加载 console.log(Module._luaL_newstate); // 应返回 function const L = Module._luaL_newstate(); console.log(Module._luaL_dostring(L, "print('Hello from WebGL')")); // 应返回 0

如果_luaL_newstate是undefined，说明xlua.bc没被正确链接，检查Assets/Plugins/WebGL/下的文件名是否为xlua.bc（不是xlua.wasm），且 Unity Editor 的Player Settings > Publishing Settings > Compression Format设为Disabled（WASM 压缩会破坏符号）。

3.5 Windows/macOS Standalone：DLL/DYLIB 编译与运行时依赖

Standalone 平台看似简单，实则隐藏着 CRT 运行时冲突。xLua 2.4.0 用/MD动态链接 CRT，而 Unity 2021.3 的UnityPlayer.dll是/MT静态链接。两者混用会导致malloc/free内存管理错乱，程序随机崩溃。

Windows 编译要点：

• Visual Studio 项目属性 →Configuration Properties > C/C++ > Code Generation > Runtime Library→ 设为Multi-threaded (/MT)；
• Linker > General > Enable Incremental Linking→No；
• 编译后用dumpbin /exports xlua.dll检查导出函数，确保luaL_newstate在列表中。

macOS 编译要点：

• clang++ -dynamiclib -std=c++11 -mmacosx-version-min=10.15 -undefined dynamic_lookup -o libxlua.dylib xlua.o tolua.o ...；
• 关键参数-undefined dynamic_lookup允许链接时忽略UnityPlayer符号，运行时由 dyld 动态解析；
• 编译后用otool -L libxlua.dylib检查依赖，应只显示@rpath/UnityPlayer.dylib，而非绝对路径。

4. 升级后必做的五项验证：从编辑器到真机的全链路测试清单

升级 xLua 并编译完所有平台链接库，只是完成了 50%。剩下 50% 是验证。我总结了一套覆盖 99% 场景的验证清单，每一条都来自真实线上事故：

4.1 编辑器内基础功能验证（10 分钟）

这是第一道防火墙，必须在提交代码前完成：

• ✅LuaEnv初始化：new LuaEnv()不抛异常；
• ✅DoString执行：env.DoString("print(1+1)")输出2；
• ✅ C# 调用 Lua 函数：定义function add(a,b) return a+b end，C# 侧env.Global.GetInPath("add").Func<int, int, int>()(1,2)返回3；
• ✅ Lua 调用 C# 方法：C# 类加[CSharpCallLua]，Lua 侧CS.UnityEngine.Debug.Log("test")正常输出；
• ✅ GC 回收：反复new LuaEnv()+Dispose()，观察 Unity Profiler 的GC Alloc是否稳定（不应持续增长）。

注意：Unity 编辑器使用 Mono 后端，而真机用 IL2CPP。编辑器能过不代表真机能过，但编辑器过不了，真机一定挂。

4.2 Android 真机专项测试（30 分钟）

重点验证 IL2CPP 与 NDK 的 ABI 兼容性：

• ✅ 启动即初始化：App 启动时LuaEnv创建成功，无UncaughtExceptionHandler日志；
• ✅ JNI 调用链路：Lua 调用CS.UnityEngine.Application.targetFrameRate = 60，观察帧率是否生效；
• ✅ 大对象传递：Lua 创建 1MB 字符串，C# 侧byte[]接收，Length正确；
• ✅ 异常传播：Lua 中error("test")，C# 侧try-catch捕获到LuaException，Message 为"test"；
• ✅ 内存泄漏：连续 100 次env.DoString("collectgarbage()")，adb shell dumpsys meminfo your.package.name显示 PSS 值稳定。

4.3 iOS 真机与 TestFlight 测试（45 分钟）

苹果审核对符号和 Bitcode 极其敏感：

• ✅ Archive 成功：Xcode Organizer 中Validate和Upload无错误；
• ✅ 启动不闪退：安装后首次启动，NSLog输出xLua init success；
• ✅ Objective-C 互操作：Lua 调用CS.UIViewController的方法，界面正常弹出；
• ✅ 后台唤醒：App 进入后台再唤醒，LuaEnv仍可用（验证static变量生命周期）；
• ✅ App Store Connect 报告：上传后检查Processing状态，确认无ITMS-90338: Non-public API usage警告（xLua 不使用私有 API，此警告通常因符号冲突引起）。

4.4 WebGL 浏览器兼容性测试（20 分钟）

WebGL 的坑在于浏览器引擎差异：

• ✅ Chrome/Firefox/Edge 最新版：Module._luaL_newstate存在，DoString正常；
• ✅ Safari 15.4+：WebAssembly.instantiateStreaming成功，无CompileError；
• ✅ 移动端 Safari：页面加载后 3 秒内LuaEnv初始化完成（Safari 对 WASM 初始化有超时限制）；
• ✅ 内存增长：反复执行env.DoString("for i=1,1000 do table.insert({},i) end")，Chrome Task Manager 中JavaScript Memory不持续上涨；
• ✅ IDBFS 兼容：若项目用IDBFS，验证env.DoString("io.open('/data/test.txt','w')")成功（xLua 2.4.4 修复了 WebGL 下io库的路径问题）。

4.5 Standalone 平台稳定性压测（60 分钟）

Standalone 常被忽视，却是热更服务器的基石：

• ✅ Windows 7/10/11 兼容：在三台不同系统上运行，luaL_newstate返回非空指针；
• ✅ macOS 10.15/11/12 兼容：dlopen("libxlua.dylib", RTLD_NOW)成功；
• ✅ 长时间运行：连续运行 24 小时，top -pid <pid>观察%CPU和RSS稳定；
• ✅ 多实例并发：启动 5 个独立进程，每个进程new LuaEnv()，无Access Violation；
• ✅ 热更模拟：运行时卸载LuaEnv，加载新 Lua 脚本，功能正常（验证Dispose后资源释放干净）。

5. 常见问题与排查技巧实录：那些让你熬夜到凌晨三点的 Bug

以下问题，全部来自我亲身踩过的坑，附带定位方法和一行解决命令。没有“可能”、“试试看”，只有确定性答案。

5.1 问题速查表：症状、原因、解决方案

5.2 独家避坑技巧：教科书不会写的实战经验

技巧 1：用nm命令秒杀符号问题

当怀疑链接库缺少某个函数时，不要猜，直接查：

# Android SO arm-linux-androideabi-nm -D libxlua.so \| grep "luaL_newstate" # iOS A nm -U libxlua.a \| grep "luaL_newstate" # Windows DLL dumpbin /exports xlua.dll \| findstr "luaL_newstate" # macOS DYLIB nm -U libxlua.dylib \| grep "luaL_newstate"

如果nm输出为空，说明该符号根本没被导出，立刻检查xlua.c中的XLUA_EXPORT宏定义。

技巧 2：Unity 编辑器内模拟 IL2CPP 环境

编辑器默认用 Mono，但你可以强制它用 IL2CPP 测试：

• Edit > Preferences > External Tools，设置Android SDK和NDK路径；
• File > Build Settings，切换到Android平台；
• 勾选Build System = Internal，Target Architectures = ARM64；
• 点击Switch Platform，Unity 会重新编译脚本；
• 此时LuaEnv初始化走的就是 IL2CPP 路径，能提前暴露 ABI 问题。

技巧 3：WebGL 的 WASM 初始化超时调试法

Safari 对 WASM 初始化有 10 秒硬限制。如果xlua.bc过大（>5MB），就会超时：

• 在index.html的UnityLoader.js中，找到createWasm函数；
• 在fetch后添加console.time("WASM load")，then中加console.timeEnd("WASM load")；
• 如果耗时 >8 秒，用emcc -s TOTAL_MEMORY=67108864增大内存，或用emcc -O2优化编译。

技巧 4：iOS 符号冲突的终极解法

当libxlua.a和 Unity 的liblua.a冲突时，除了改函数名，还可以：

• 在build_ios.sh中，CFLAGS加-DLUA_COMPAT_ALL，让 xLua 使用兼容模式；
• 在 Xcode 的Build Settings > Other C Flags中，添加-fvisibility=hidden，隐藏 xLua 的全局符号；
• 最后，在Unity-iPhone/Classes/UnityAppController.mm中，#import "xlua.h"前加#define lua_open xlua_open，彻底隔离命名空间。

技巧 5：自动化编译脚本防错设计

手敲命令容易出错，我用 Python 写了个校验脚本verify_xlua.py：

import subprocess import sys def check_so_symbols(so_path): result = subprocess.run(['arm-linux-androideabi-nm', '-D', so_path], capture_output=True, text=True) if 'luaL_newstate' not in result.stdout: print(f"ERROR: {so_path} missing luaL_newstate") sys.exit(1) if __name__ == "__main__": check_so_symbols("Assets/Plugins/Android/libxlua.so") check_so_symbols("Assets/Plugins/iOS/libxlua.a") # nm for static lib

每次编译后运行python verify_xlua.py，5 秒内告诉你是否合格。

6. 升级后的长期维护建议：让 xLua 成为你项目的稳定基石

xLua 升级不是一次性任务，而是持续的工程实践。基于 7 个项目的经验，我给出三条硬性建议：

6.1 建立“xLua 版本锁”机制

不要在Assets/Plugins/xLua/下直接放源码。而是：

• 创建ThirdParty/xLua/2.4.4/目录，存放完整源码、编译脚本、预编译库；
• 在Assets/Plugins/xLua/中只放软链接（macOS/Linux）或.meta文件（Windows）；
• git submodule add https://github.com/Tencent/xLua.git ThirdParty/xLua/2.4.4；
• 每次升级，新建2.4.5/目录，编译验证通过后，再切换软链接。

这样，不同分支可以锁定不同 xLua 版本，避免“一次升级，全队加班”。

6.2 编写平台专属的BuildPostprocessor

Unity 的BuildPlayerPipeline可以在构建前自动注入平台配置：

public class XluaBuildProcessor : IPreprocessBuildWithReport { public int callbackOrder => 0; public void OnPreprocessBuild(PreprocessBuildReport report) { if (report.summary.platform == BuildTarget.Android) { // 自动复制对应 NDK 版本的 libxlua.so File.Copy("ThirdParty/xLua/2.4.4/Android/r21e/libxlua.so", "Assets/Plugins/Android/libxlua.so", true); } if (report.summary.platform == BuildTarget.iOS) { // 自动设置 Xcode 的 Enable Bitcode = NO PlayerSettings.SetPropertyString("iOS.EnableBitcode", "False", BuildTargetGroup.iOS); } } }

把这种琐碎操作自动化，比写文档管用一百倍。

6.3 为 QA 团队提供“xLua 健康检查”工具

开发一个简单的 Unity Editor 工具，一键检测：

• 当前 xLua 版本号（读取XLua.dll的AssemblyVersion）；
• 各平台链接库是否存在、大小是否合理（Android SO > 500KB，iOS A > 2MB）；
• LuaEnv初始化耗时（毫秒级）；
• 内存占用基线（`Profiler.GetTotalAlloc