1. 项目概述当FGUI插件开发遇上C#文件操作如果你正在用FGUIFairyGUI为Unity项目开发编辑器插件并且需要在Lua脚本里调用C#的System.IO来操作文件那你很可能已经踩过或者即将踩进一些“坑”里。这不仅仅是简单的API调用而是横跨了FGUI的UI逻辑层、Lua虚拟机、Unity的C#主线程以及操作系统文件系统的一场“协同作战”。我最近刚完成一个需要批量导出UI配置、生成资源清单的插件整个过程可以说是“坑”出不穷从Lua调用C#方法时诡异的参数传递到System.IO在多线程环境下的权限冲突再到路径处理在不同操作系统下的兼容性问题每一个环节都可能让你调试到怀疑人生。这篇指南就是把我趟过的这些雷区、以及最终找到的稳定解决方案系统地梳理出来。无论你是想实现一个自定义的UI资源打包工具还是做一个自动化的配置检查插件理解这些底层交互的细节都能帮你省下大量无谓的调试时间。2. 核心架构与交互原理拆解在开始填坑之前我们必须先搞清楚FGUI插件开发中Lua、C#和Unity编辑器三者是如何协同工作的。很多问题根源就在于对这套机制理解不透彻。2.1 FGUI插件、Lua与Unity C#的三层关系FGUI编辑器本身是一个用JavaScript/TypeScript开发的Electron应用但它通过一个名为“插件桥”的机制与Unity编辑器进程通信。当你开发一个FGUI插件时你的主要逻辑是用Lua脚本编写的运行在FGUI编辑器内置的Lua虚拟机中。这些Lua脚本无法直接访问Unity项目中的C#类库也无法直接调用系统API。这时就需要C#端提供一个“桥梁”。你需要在Unity项目中创建一个C#类库通常是一个Editor文件夹下的脚本这个类库通过特定的接口如IPluginInterface向FGUI编辑器注册一系列方法。FGUI编辑器中的Lua脚本则通过类似CS.SomeNamespace.SomeClass:SomeMethod()的语法来远程调用这些注册好的C#方法。这个过程本质上是进程间通信IPC数据需要经过序列化和反序列化。注意很多人误以为Lua调用C#是“直接”的就像在Unity游戏运行时用XLua那样。实际上在编辑器插件环境下这是一个跨进程的远程调用延迟和错误处理机制完全不同。2.2 System.IO在Unity编辑器环境下的特殊性你的C#插件方法里肯定会用到System.IO命名空间下的类比如File,Directory,Path,FileStream等。但在Unity编辑器环境下使用它们有几个关键的特殊性线程上下文从FGUI Lua发起的调用最终会在Unity的主线程上执行你的C#方法。这意味着如果你的文件操作比较耗时会阻塞Unity编辑器的主线程导致界面卡死。然而你又不能简单地在C#方法里开一个新线程去做IO因为对新线程中文件状态的修改可能无法及时反馈到FGUI的Lua脚本中并且涉及UI更新的操作必须回到主线程。路径基准System.IO的默认当前目录Environment.CurrentDirectory很可能是Unity编辑器的安装目录而不是你的项目目录。直接使用相对路径如./output/data.json会导致文件写到意想不到的地方。必须使用Application.dataPath、Application.persistentDataPath等Unity提供的API来获取绝对路径。沙盒与权限在某些操作系统如macOS或特定安全策略下Unity编辑器可能运行在一定的沙盒环境中对某些系统目录如Program Files或/usr的写入操作会被禁止导致UnauthorizedAccessException。理解了这些底层原理我们再来看看具体会踩到哪些坑以及如何避开它们。3. 从Lua到C#API调用层的“坑”与填法这是第一道关卡如果调用都通不了后面的文件操作就无从谈起。3.1 坑一Lua调用C#静态方法与实例方法的语法混淆在FGUI的Lua环境中调用C#方法语法有严格规定。静态方法和实例方法的调用方式不同用错了就会收到attempt to call a nil value的错误。错误示范-- 假设C#类 FileExporter 有一个静态方法 ExportAll local result CS.FileExporter.ExportAll(uiList) -- 错误这是C#中的调用方式在FGUI Lua中不适用 -- 假设C#类 FileExporter 有一个实例方法 ExportSingle local exporter CS.FileExporter() -- 错误尝试创建实例但通常插件类不这样实例化 local result exporter:ExportSingle(uiName)正确填法FGUI Lua到C#的桥接通常要求C#端将方法注册为“插件命令”。更常见的做法是C#类提供一个静态的“门面”方法该方法内部处理实例化或直接执行逻辑。C#端代码示例using FairyGUI.Editor; using System.Collections.Generic; public class MyFilePlugin : IPlugin { public void OnInstall() { // 注册一个名为 exportUI 的命令关联到静态方法 HandleExportCommand PluginManager.RegisterCommand(exportUI, HandleExportCommand); } private static object HandleExportCommand(object[] args) { // args 是从Lua传递过来的参数数组 if (args.Length 0 args[0] is Listobject uiNames) { // 在这里进行实际的System.IO操作 string exportPath Path.Combine(Application.dataPath, ExportedUI); Directory.CreateDirectory(exportPath); // ... 更多文件操作 return 导出成功路径 exportPath; } return 参数错误; } }Lua端调用示例-- 通过 PluginManager 调用注册的命令 local result PluginManager:CallCommand(exportUI, {UI_Login, UI_Main}) if result then print(调用结果, result) end关键在于使用PluginManager:CallCommand而不是直接调用C#类。参数传递是一个object数组在C#端需要仔细处理类型转换。3.2 坑二复杂数据类型的序列化与传递丢失Lua中的表table在传递给C#时会被转换为什么类型如果直接传递一个复杂的嵌套表很可能在C#端接收到的是一个空洞的Listobject里面的结构丢失了。错误场景Lua端传递一个包含UI组件信息的复杂结构local uiData { name UI_Login, components { { type Button, id btnOK, pos { x100, y200 } }, { type Image, id bg, url ui://package/bg } } } local result PluginManager:CallCommand(processUIData, uiData)C#端如果直接用args[0] as Dictionarystring, object来接收可能会发现components的内容无法正确解析。填法使用JSON作为中间交换格式这是最稳妥、跨语言兼容性最好的方案。不要尝试直接传递复杂的Lua对象。在Lua端将数据序列化为JSON字符串。FGUI环境通常内置或可以引入一个JSON库如cjson。local json require cjson local uiData { ... } -- 你的复杂数据 local jsonString json.encode(uiData) local result PluginManager:CallCommand(processUIDataJson, jsonString)在C#端使用Newtonsoft.JsonUnity已内置反序列化。using Newtonsoft.Json; using Newtonsoft.Json.Linq; private static object HandleProcessUIDataJson(object[] args) { if (args.Length 0 args[0] is string jsonStr) { try { JObject uiData JObject.Parse(jsonStr); string uiName uiData[name]?.ToString(); // 可以继续解析复杂的components数组 var components uiData[components] as JArray; foreach (var comp in components) { string type comp[type]?.ToString(); // ... 处理每个组件 } // 处理完成后如果需要返回复杂数据给Lua同样序列化成JSON字符串返回 return JsonConvert.SerializeObject(new { success true, message 处理完成 }); } catch (JsonException e) { return JsonConvert.SerializeObject(new { success false, error e.Message }); } } return null; }这样数据的完整性和结构就得到了保证避免了因跨语言类型映射不匹配导致的数据丢失。4. System.IO文件操作中的致命陷阱当你的C#方法成功被调用开始进行文件操作时真正的“硬坑”才刚刚开始。4.1 坑三路径问题——相对路径的“幽灵写入”这是最常见也最隐蔽的问题。在Unity编辑器环境下System.IO默认的当前工作目录是不确定的。错误示范// 在C#插件方法中 string configPath Assets/Config/ui_settings.asset; // 这是一个相对于项目Assets的路径 if (File.Exists(configPath)) // 这个判断很可能为false因为当前目录可能不是项目根目录 { string content File.ReadAllText(configPath); // 即使文件存在这里也可能抛出FileNotFoundException }填法永远使用绝对路径并依赖Unity的路径APIusing UnityEngine; using System.IO; private static void SafeFileOperation() { // 方法1使用 Application.dataPath。注意它指向Assets文件夹的绝对路径末尾自带/Assets。 string absoluteConfigPath Path.Combine(Application.dataPath, Config/ui_settings.asset); // 但 Application.dataPath 是只读的不你可以写它的子目录。对于需要导出的文件通常放在外部。 // 方法2对于插件生成的文件推荐使用 Application.persistentDataPath。 // 它在不同平台有固定位置且应用有读写权限。 string exportDir Path.Combine(Application.persistentDataPath, FGUI_Exports); Directory.CreateDirectory(exportDir); // 确保目录存在 string exportFilePath Path.Combine(exportDir, ui_list.json); // 方法3如果需要让用户选择路径使用UnityEditor.EditorUtility.SaveFilePanel #if UNITY_EDITOR string userSelectedPath UnityEditor.EditorUtility.SaveFilePanel(保存配置, , ui_config, json); if (!string.IsNullOrEmpty(userSelectedPath)) { File.WriteAllText(userSelectedPath, jsonContent); } #endif }实操心得我习惯在插件初始化时就在Application.persistentDataPath下创建一个以插件名命名的子目录所有插件生成的文件都放在这里。这样既清晰又避免了权限问题还方便用户清理。4.2 坑四文件占用与异步操作冲突当你尝试读取或写入一个文件时如果该文件已被其他进程甚至是同一进程内的其他线程或编辑器本身打开并锁定就会抛出IOException提示“文件正在被另一进程使用”。典型场景你导出了一个JSON文件然后用默认程序如记事本、VSCode打开了它并且没有关闭。你的插件在写入文件的过程中Unity编辑器自动刷新了AssetDatabase试图导入这个正在被写入的文件。你写的C#方法内部使用了File.ReadAllText然后立即又想用FileStream以写入模式打开同一个文件但没有妥善关闭第一个流。填法精细控制文件流生命周期与使用重试机制private static string ReadFileWithRetry(string filePath, int maxRetry 3) { IOException lastException null; for (int i 0; i maxRetry; i) { try { // 使用File.ReadAllText是最简单的但它内部会打开并关闭流。 // 对于小文件这通常就够了。 return File.ReadAllText(filePath); } catch (IOException ex) when (IsFileLocked(ex)) { lastException ex; // 等待一小段时间再重试 System.Threading.Thread.Sleep(50 * (i 1)); // 递增等待 } } UnityEngine.Debug.LogError($无法读取文件 {filePath}已重试{maxRetry}次。错误{lastException?.Message}); return null; } private static void WriteFileSafely(string filePath, string content) { string tempFilePath filePath .tmp; try { // 先写入临时文件 File.WriteAllText(tempFilePath, content); // 写入成功后再替换原文件。File.Replace是原子操作更安全。 File.Replace(tempFilePath, filePath, backupPath: null); } catch (Exception ex) { UnityEngine.Debug.LogError($写入文件失败: {ex.Message}); // 清理临时文件 if (File.Exists(tempFilePath)) { try { File.Delete(tempFilePath); } catch { } } throw; // 或者返回错误信息 } } // 辅助方法判断异常是否因文件被占用引起 private static bool IsFileLocked(IOException ex) { int errorCode System.Runtime.InteropServices.Marshal.GetHRForException(ex) 0xFFFF; // 错误码32: 文件正在被使用错误码33: 文件被锁定 return errorCode 32 || errorCode 33; }对于写入操作采用“写临时文件替换”的模式可以最大程度避免写出不完整文件也减少了原文件被锁定的时间窗口。4.3 坑五跨平台路径分隔符与文件名合法性你的插件可能在Windows的Unity上开发但其他团队成员用macOS。System.IO.Path.Combine会自动处理平台分隔符但如果你自己拼接字符串就很容易出问题。错误示范string badPath exportDir \\ subDir \\ fileName; // Windows风格在macOS/Linux上失效 string badFileName UI:Main?Screen; // 包含非法字符填法使用Path类辅助并严格校验文件名private static string EnsureValidFilePath(string baseDir, string subDir, string desiredFileName) { // 1. 使用Path.Combine构建路径 string fullDir Path.Combine(baseDir, subDir); Directory.CreateDirectory(fullDir); // 2. 清理文件名中的非法字符 char[] invalidChars Path.GetInvalidFileNameChars(); string safeFileName string.Join(_, desiredFileName.Split(invalidChars, StringSplitOptions.RemoveEmptyEntries)); // 3. 避免文件名过长某些系统有路径长度限制 if (safeFileName.Length 100) // 设定一个合理上限 { safeFileName safeFileName.Substring(0, 50) _ Path.GetFileNameWithoutExtension(safeFileName).GetHashCode().ToString(x) Path.GetExtension(safeFileName); } // 4. 最终组合 return Path.Combine(fullDir, safeFileName); }此外对于需要用户输入的文件名部分一定要做合法性检查防止因为一个非法字符导致整个文件操作失败。5. 性能、异常处理与调试技巧即使单个操作没问题当处理大批量UI文件时性能和稳定性就成了新挑战。5.1 坑六阻塞主线程导致FGUI编辑器无响应如果你的C#插件方法需要处理成百上千个UI组件每个都涉及文件读写那么这个方法执行时间可能会很长。由于这个调用最终是在Unity主线程上执行的会导致Unity编辑器界面“卡死”FGUI编辑器也会因为等待响应而失去响应。填法将耗时操作放入后台线程并通过回调通知完成我们不能在C#插件方法内部直接启动线程然后立即返回因为Lua需要知道操作结果。但我们可以实现一个“异步任务”模式。C#端实现一个简单的任务队列using System.Collections.Concurrent; using System.Threading; using System.Threading.Tasks; public static class AsyncFileTaskManager { private static ConcurrentQueueAction _mainThreadCallbacks new ConcurrentQueueAction(); // 在Unity主线程的更新循环中调用此方法需要借助[InitializeOnLoad]和EditorApplication.update public static void Update() { while (_mainThreadCallbacks.TryDequeue(out var action)) { action?.Invoke(); } } public static void StartFileExportTask(Liststring uiList, Actionstring onComplete) { Task.Run(() { string result 开始导出...; try { // 这里是耗时的System.IO操作 foreach (var uiName in uiList) { // 模拟耗时操作 Thread.Sleep(100); // 实际可能是读取、解析、写入文件 string filePath Path.Combine(Application.persistentDataPath, ${uiName}.json); File.WriteAllText(filePath, ${{ \name\: \{uiName}\ }}); } result $成功导出 {uiList.Count} 个文件; } catch (Exception ex) { result $导出失败: {ex.Message}; } // 将结果回调排队到主线程执行 string finalResult result; // 闭包捕获 _mainThreadCallbacks.Enqueue(() onComplete?.Invoke(finalResult)); }); } }在C#插件命令中调用private static object HandleAsyncExport(object[] args) { if (args[0] is Listobject list) { var uiNames list.Caststring().ToList(); // 立即返回一个任务ID而不是等待完成 Guid taskId Guid.NewGuid(); AsyncFileTaskManager.StartFileExportTask(uiNames, (result) { // 当后台任务完成时如何通知Lua这里需要一个回调机制。 // 一种方法是让Lua轮询另一种是FGUI插件支持事件推送。 // 简单起见可以先记录日志让用户知道去查看。 UnityEngine.Debug.Log($导出任务完成: {result}); // 更复杂的实现可以将结果存入一个共享字典Lua通过另一个命令来获取。 }); return taskId.ToString(); // 返回任务ID供查询 } return invalid_args; }Lua端调用命令后立即得到任务ID然后可以定期通过另一个命令如checkTaskStatus来查询任务是否完成并获取结果。这样FGUI界面就不会卡住。5.2 坑七异常被“吞掉”Lua端得不到错误信息C#端代码抛出异常如果没有被正确捕获并传递回Lua那么在Lua端看来这次调用可能就是简单地返回了nil没有任何错误提示调试起来极其困难。填法统一的异常捕获与错误信息返回格式在C#插件命令的入口处包裹一个全局的try-catch。private static object SafeCommandWrapper(string commandName, Funcobject[], object commandFunc, object[] args) { try { return commandFunc(args); } catch (System.Exception e) { // 记录详细的错误日志到Unity控制台 UnityEngine.Debug.LogError($[FGUI Plugin {commandName} Error] {e.GetType().Name}: {e.Message}\nStackTrace: {e.StackTrace}); // 返回一个Lua能解析的、结构化的错误信息例如JSON var errorInfo new { success false, error true, command commandName, message e.Message, type e.GetType().Name }; return JsonConvert.SerializeObject(errorInfo); } } // 注册命令时这样包装 PluginManager.RegisterCommand(exportUI, (args) SafeCommandWrapper(exportUI, HandleExportCommand, args));在Lua端你需要检查返回结果。如果结果是字符串尝试解析JSON判断是否有error字段。local result PluginManager:CallCommand(exportUI, {...}) if type(result) string then local ok, data pcall(json.decode, result) if ok and data and data.error then print(插件调用出错, data.message) -- 在FGUI编辑器中显示错误提示 -- ... return end end -- 正常处理结果5.3 调试技巧如何定位Lua-C#-IO问题当问题发生时你需要知道问题出在哪个环节。在Lua端加日志在调用PluginManager:CallCommand前后打印参数和结果。在C#端使用UnityEngine.Debug.Log这是最直接的输出到Unity控制台的方式。在方法开始、关键步骤、异常捕获处都加上日志。使用Unity的Player.log或编辑器日志文件如果Unity编辑器控制台看不到输出有时插件日志会被淹没可以去查找日志文件。Windows通常在%USERPROFILE%\AppData\Local\Unity\Editor\Editor.log。使用文件日志作为最后的手段在C#端将关键信息如传入参数、中间状态、异常详情直接写入一个文本文件。当其他日志都失效时这个文件是救命稻草。private static void LogToFile(string message) { string logPath Path.Combine(Application.persistentDataPath, fgui_plugin_log.txt); try { File.AppendAllText(logPath, $[{DateTime.Now:yyyy-MM-dd HH:mm:ss}] {message}{Environment.NewLine}); } catch { /* 忽略日志写入错误 */ } }6. 一个完整的实战案例UI组件依赖资源导出器假设我们要开发一个插件功能是分析FGUI项目中的UI组件找出所有引用的图片、字体等资源并将这些资源的路径列表导出为一个CSV文件。这个案例会综合运用上述所有知识点。6.1 设计思路与C#端核心代码C#端 (UIResourceExporter.cs):using FairyGUI.Editor; using Newtonsoft.Json; using Newtonsoft.Json.Linq; using System.Collections.Generic; using System.IO; using System.Linq; using System.Text; using UnityEngine; public class UIResourceExporter : IPlugin { public void OnInstall() { PluginManager.RegisterCommand(exportResourceList, HandleExportResourceList); } private static object HandleExportResourceList(object[] args) { // 1. 接收Lua传来的UI包和组件列表JSON格式 if (args.Length 1 || !(args[0] is string jsonArgs)) return CreateErrorResult(参数错误缺少JSON数据); try { JObject request JObject.Parse(jsonArgs); string packageName request[package]?.ToString(); JArray componentArray request[components] as JArray; if (string.IsNullOrEmpty(packageName) || componentArray null) return CreateErrorResult(参数错误缺少包名或组件列表); Liststring componentList componentArray.Select(c c.ToString()).ToList(); // 2. 准备导出目录使用persistentDataPath string exportDir Path.Combine(Application.persistentDataPath, FGUI_ResourceExports); Directory.CreateDirectory(exportDir); string csvFilePath Path.Combine(exportDir, ${packageName}_resources_{DateTime.Now:yyyyMMddHHmmss}.csv); // 3. 模拟资源分析实际中这里需要调用FGUI Editor API来获取组件依赖 // 这里我们用假数据演示 ListResourceInfo resourceInfos AnalyzeComponentResources(packageName, componentList); // 4. 生成CSV内容 StringBuilder csvContent new StringBuilder(); csvContent.AppendLine(Component,ResourceType,ResourceURL,FileSize(估计)); foreach (var res in resourceInfos) { // 处理可能包含逗号的字段用双引号包裹 csvContent.AppendLine($\{res.ComponentName}\,{res.Type},\{res.Url}\,{res.EstimatedSize}); } // 5. 安全写入文件使用临时文件替换 string tempFilePath csvFilePath .tmp; File.WriteAllText(tempFilePath, csvContent.ToString(), Encoding.UTF8); // 指定UTF8编码 if (File.Exists(csvFilePath)) File.Delete(csvFilePath); File.Move(tempFilePath, csvFilePath); // 6. 返回成功结果包含文件路径 return JsonConvert.SerializeObject(new { success true, message $资源列表导出成功, filePath csvFilePath, count resourceInfos.Count }); } catch (JsonException je) { return CreateErrorResult($JSON解析失败: {je.Message}); } catch (IOException ioe) { return CreateErrorResult($文件操作失败: {ioe.Message}); } catch (System.Exception e) { return CreateErrorResult($未知错误: {e.Message}); } } private static ListResourceInfo AnalyzeComponentResources(string packageName, Liststring components) { // 这里是模拟分析逻辑。真实场景需要调用FGUI编辑器接口。 // 例如对于每个组件名获取其依赖的贴图、字体等资源的URL。 var result new ListResourceInfo(); foreach (var comp in components) { // 模拟找到一些图片资源 result.Add(new ResourceInfo { ComponentName comp, Type Image, Url $ui://{packageName}/btn_normal, EstimatedSize 2048 }); result.Add(new ResourceInfo { ComponentName comp, Type Image, Url $ui://{packageName}/bg_main, EstimatedSize 4096 }); // 模拟找到字体资源 result.Add(new ResourceInfo { ComponentName comp, Type Font, Url 微软雅黑, EstimatedSize 0 }); } return result; } private static string CreateErrorResult(string message) { return JsonConvert.SerializeObject(new { success false, error message }); } private class ResourceInfo { public string ComponentName { get; set; } public string Type { get; set; } public string Url { get; set; } public long EstimatedSize { get; set; } } }6.2 Lua端调用与界面集成Lua端脚本 (resource_export.lua):local json require cjson function onExportButtonClick() -- 假设从界面上获取了选中的包和组件 local selectedPackage MainPackage local selectedComponents {UI_Login, UI_Main, UI_Setting} -- 1. 构建请求参数JSON格式 local requestData { package selectedPackage, components selectedComponents } local jsonArgs json.encode(requestData) -- 2. 调用C#插件命令 local result PluginManager:CallCommand(exportResourceList, jsonArgs) -- 3. 解析返回结果 if type(result) string then local ok, data pcall(json.decode, result) if ok and data then if data.success then -- 导出成功显示结果 local message string.format(成功导出%d条资源记录。\n文件已保存至%s, data.count, data.filePath) -- 在FGUI编辑器中弹出成功提示假设有Alert函数 Alert(message, 导出成功) -- 可以尝试用系统默认程序打开文件所在目录需要C#端再提供一个命令 -- openFileExplorer(data.filePath) else -- 导出失败显示错误 Alert(导出失败 .. (data.error or 未知错误), 错误) end else Alert(解析插件返回结果失败 .. tostring(result), 错误) end else Alert(插件调用返回了非字符串结果 .. type(result), 错误) end end -- 将函数绑定到FGUI按钮的点击事件 -- someButton.onClick:Set(onExportButtonClick)6.3 案例中的避坑点总结数据传递使用JSON作为Lua和C#之间的数据交换格式避免了复杂类型序列化问题。路径安全导出目录使用Application.persistentDataPath确保了跨平台兼容性和写入权限。文件写入采用先写临时文件(.tmp)再移动覆盖的方式保证了文件写入的原子性即使中途崩溃也不会留下损坏的半成品文件。编码指定使用File.WriteAllText(..., Encoding.UTF8)明确指定UTF-8编码防止中文等字符在跨平台时出现乱码。异常处理在C#端对所有可能出错的地方JSON解析、IO操作进行了捕获并将错误信息结构化为JSON返回给Lua便于前端展示。结果反馈返回的JSON中包含了操作结果、消息、文件路径和数据量信息完整方便Lua端进行后续处理如打开目录、显示统计。7. 进阶优化与扩展思路当你掌握了基本的避坑方法后可以考虑以下优化来让你的插件更健壮、更专业。7.1 实现进度反馈机制对于耗时长的导出任务让用户看到进度至关重要。由于C#后台线程不能直接更新FGUI的Lua界面我们可以通过“进度状态查询”的方式来实现。C#端维护一个全局的DictionaryGuid, ExportProgress用于存储每个导出任务的进度。public class ExportProgress { public Guid TaskId { get; set; } public string Status { get; set; } // Running, Completed, Failed public int Current { get; set; } public int Total { get; set; } public string CurrentItem { get; set; } public string ResultFilePath { get; set; } public string ErrorMessage { get; set; } } // 在异步任务中更新进度 private static void UpdateProgress(Guid taskId, int current, int total, string currentItem) { if (_progressDict.TryGetValue(taskId, out var progress)) { progress.Current current; progress.Total total; progress.CurrentItem currentItem; } }新增一个C#命令getExportProgress接收任务ID返回当前的进度信息JSON。Lua端启动任务后启动一个定时器如每0.5秒轮询调用getExportProgress根据返回的进度信息更新UI上的进度条和状态文本。7.2 增加操作撤销Undo支持如果你的插件会修改Unity项目内的资源例如根据分析结果自动重命名或移动图片文件那么支持Unity的撤销操作是专业插件的体现。使用UnityEditor.Undo.RecordObject在修改资源前进行记录。#if UNITY_EDITOR using UnityEditor; private static void ModifyAssetWithUndo(string assetPath) { var asset AssetDatabase.LoadAssetAtPathTexture2D(assetPath); // 举例修改一个贴图 if (asset ! null) { // 开始记录Undo操作 Undo.RecordObject(asset, Update Asset Import Settings via FGUI Plugin); // 进行你的修改... TextureImporter importer AssetImporter.GetAtPath(assetPath) as TextureImporter; if (importer ! null) { importer.textureType TextureImporterType.Sprite; importer.SaveAndReimport(); } // 修改会自动被Undo系统记录 EditorUtility.SetDirty(asset); } } #endif这样用户在Unity编辑器中按CtrlZ就可以撤销你的插件所做的修改。7.3 插件配置的持久化插件可能需要保存一些用户设置如默认导出路径、文件格式选项等。不要将这些信息硬编码也不要试图写入FGUI编辑器的安装目录。推荐方案使用Unity的EditorPrefs或ScriptableObject。EditorPrefs适合存储简单的键值对。#if UNITY_EDITOR string defaultPath EditorPrefs.GetString(FGUI_Plugin_DefaultExportPath, Application.persistentDataPath); EditorPrefs.SetString(FGUI_Plugin_DefaultExportPath, userSelectedNewPath); #endifScriptableObject适合存储复杂的配置结构。可以在Unity项目的Assets/Editor目录下创建一个配置资产文件。[CreateAssetMenu(fileName FGUIExporterSettings, menuName FGUI/Exporter Settings)] public class ExporterSettings : ScriptableObject { public string defaultExportDirectory; public Liststring excludedComponentTypes; public bool autoOpenAfterExport; }然后在插件初始化时加载这个配置资产修改后保存。开发FGUI插件尤其是在其中集成复杂的C#文件操作就像是在一座精致的玻璃桥上施工需要格外小心。核心在于深刻理解Lua与C#之间是远程调用System.IO在编辑器环境下有其特殊性。记住几个黄金法则数据传递用JSON、路径操作用绝对路径和Path.Combine、文件写入用“临时文件替换”策略、耗时操作丢给后台线程并做好进度反馈、异常一定要捕获并返回给前端。把这些点做到位你开发的插件就能从“勉强能用”升级到“稳定可靠”真正成为团队工作流中提效的利器而不是一个时不时需要你亲自去“救火”的麻烦来源。