企业官网建设流程全解析

1. 项目缘起：为什么Unity开发者需要关注文件对话框？

在Unity项目开发中，处理本地文件是一个绕不开的环节。无论是编辑器工具开发、运行时数据导入导出，还是游戏配置管理，我们常常需要让用户选择文件路径或指定保存位置。很多开发者，尤其是刚接触Unity不久的朋友，可能会觉得这应该是个简单的API调用，但实际动手时却发现，Unity并没有提供一个跨平台、开箱即用的“万能”文件对话框。你可能会在论坛里看到各种提问：“Unity怎么像Windows那样弹出一个选择文件的窗口？”、“在Mac上打包的PC游戏，如何让玩家选择存档位置？”。

这正是我们今天要深入探讨的核心问题。Unity作为一个跨平台的游戏引擎，其设计哲学是抽象底层系统差异，提供一套统一的API。然而，文件系统对话框恰恰是高度依赖操作系统原生UI的组件。因此，Unity官方提供了一套方案，但它的能力边界和适用场景非常明确。同时，社区和开发者们也探索出了其他几种“野路子”，各有各的适用场景和坑点。

我自己在开发编辑器扩展、数据工具以及一些需要玩家自定义内容（如Mod加载、地图导入）的PC游戏时，多次和文件对话框打交道。从最初只会用EditorUtility.OpenFilePanel，到后来为了更复杂的交互去研究Windows Forms，再到为WebGL和移动平台寻找替代方案，踩过的坑不计其数。这篇文章，我就结合这些实战经验，为你系统梳理Unity中实现文件选择和保存窗口的多种方式，帮你理解每种方法的原理、适用场景和那些官方文档里不会写的细节。

2. 官方首选：EditorUtility与StandaloneFileBrowser

对于大多数Unity项目，尤其是编辑器工具开发和PC/Mac/Linux独立平台（Standalone）的运行时，Unity官方或官方推荐的方案是首选，因为它们最稳定，兼容性也最好。

2.1 编辑器环境下的利器：EditorUtility

UnityEditor.EditorUtility类下的几个静态方法，是开发Editor工具时处理文件对话框的标准答案。它们直接调用操作系统（Windows, macOS, Linux）的原生文件对话框，体验与系统完全一致。

核心方法解析：

1. OpenFilePanel/OpenFilePanelWithFilters这是最常用的打开单个文件的方法。它的核心参数决定了其行为：

   // 基础用法 string path = EditorUtility.OpenFilePanel("选择数据文件", Application.dataPath, "json,txt,csv"); // 带过滤器的用法 string path = EditorUtility.OpenFilePanelWithFilters("选择纹理", "", new string[] {"Image files", "png,jpg,jpeg", "All files", "*"});

   • title: 对话框的标题。这里有个小技巧，在Windows上标题显示在窗口左上角，用户可能不太注意，但在macOS上，它会显示在窗口顶部中央，更显眼。
   • directory: 初始打开的目录。Application.dataPath（Assets文件夹）是常用起点，但也可以设为PlayerPrefs保存的上次路径，提升用户体验。
   • extension: 文件扩展名过滤器。可以是用逗号分隔的多个扩展名（如"png,jpg"），如果留空或设为""，则允许选择所有文件。这里有个坑：extension参数不支持像"Image files|png,jpg"这样的描述符格式，它只认纯扩展名字符串。如果需要带描述的过滤器，必须用OpenFilePanelWithFilters。
   • 返回值: 用户选择的完整文件路径（字符串）。如果用户取消了对话框，则返回空字符串""。这是必须检查的！很多崩溃都源于直接使用未检查的路径。

2. OpenFolderPanel当需要让用户选择一个文件夹（例如，指定资源导入目录、打包输出目录）时使用。

   string folderPath = EditorUtility.OpenFolderPanel("选择资源文件夹", Application.dataPath, "");

   它的行为与OpenFilePanel类似，但界面是系统原生的文件夹选择器。同样，取消操作返回空字符串。

3. SaveFilePanel/SaveFilePanelInProject用于保存文件。这是最容易出问题的地方。

   // 通用保存面板 string savePath = EditorUtility.SaveFilePanel("保存配置文件", Application.dataPath, "NewConfig", "json"); // 在项目内保存的面板（会返回相对于Assets的路径） string projectRelativePath = EditorUtility.SaveFilePanelInProject("保存项目内资源", "NewAsset", "asset", "请指定保存位置");

   • SaveFilePanel: 返回的是绝对路径。你需要自己处理文件写入和可能需要的路径转换（比如，如果你想保存在Assets内并自动导入，需要将绝对路径转换为相对于项目的路径）。
   • SaveFilePanelInProject:这是编辑器工具开发的黄金方法。它强制用户在项目目录（Assets或Packages）内选择位置，返回的路径是类似于"Assets/MyFolder/NewAsset.asset"的相对路径。并且，在用户点击保存后，如果文件是Unity可识别的类型（如.asset,.prefab），它会自动触发资源数据库刷新。这避免了手动调用AssetDatabase.Refresh()的麻烦。

实战心得与避坑指南：

• 阻塞主线程：这些对话框都是模态阻塞的。弹出时，整个Unity编辑器会停止响应，直到用户关闭对话框。这意味着你不能在对话框打开时做其他事情。对于长时间操作，务必在弹出对话框前保存场景或给出提示。
• 路径验证：永远不要相信返回的路径。即使使用了过滤器，某些操作系统（或用户手动输入）仍可能返回带有非法字符或不符合预期的扩展名的路径。在进行文件IO操作（File.ReadAllText,File.WriteAllBytes）之前，使用System.IO.Path类的方法（如GetInvalidPathChars,GetInvalidFileNameChars）或简单的string.IsNullOrEmpty进行检查是必要的。
• SaveFilePanelInProject的路径陷阱：它返回的路径以"Assets/..."开头。如果你想用System.IOAPI去写入，需要先使用Application.dataPath将其转换为绝对路径：string fullPath = Path.Combine(Application.dataPath, projectRelativePath.Substring(7));。注意Substring(7)是为了去掉开头的"Assets/"。
• 扩展名处理：SaveFilePanel的extension参数是默认扩展名。如果用户输入的文件名没有扩展名，系统会自动追加这个扩展名。但如果用户输入了其他扩展名，则以用户输入的为准。你的保存逻辑应该能处理这种情况。

2.2 运行时跨平台方案：StandaloneFileBrowser

在PC/Mac/Linux的独立游戏运行时（Runtime），EditorUtility类就不可用了，因为它属于UnityEditor命名空间。这时，社区大神们维护的StandaloneFileBrowser库就成了事实上的标准。

它是什么？这是一个开源库（GitHub上可找到），它封装了各个平台（Windows, macOS, Linux）调用原生文件对话框的底层代码。在Windows上，它可能调用GetOpenFileNameWin32 API；在macOS上，使用Cocoa的NSOpenPanel；在Linux上，则可能依赖zenity或kdialog等命令行工具。

如何使用？通常以.dll插件或源代码形式导入项目。其API设计有意模仿了EditorUtility，使用起来非常顺手：

// 引入命名空间 using SFB; // StandaloneFileBrowser的缩写 // 打开文件 var extensions = new [] { new ExtensionFilter("Image Files", "png", "jpg", "jpeg"), new ExtensionFilter("All Files", "*") }; var paths = StandaloneFileBrowser.OpenFilePanel("打开图片", "", extensions, false); if(paths.Length > 0) { string filePath = paths[0]; // 处理文件... } // 保存文件 string savePath = StandaloneFileBrowser.SaveFilePanel("保存存档", "", "MySave", new ExtensionFilter("Save File", "sav"));

核心注意事项：

• 异步回调：与编辑器API不同，StandaloneFileBrowser的某些封装版本或在不同平台上的实现，可能是非阻塞的。这意味着你调用它之后，主线程不会停止，对话框在后台弹出，用户操作完成后通过回调函数通知你。务必查看你所用版本的文档或示例，确认其调用模式。如果它是异步的，你需要把后续的文件处理逻辑放在回调函数里，否则会出现“文件还没选好，代码就已经在执行加载”的错误。
• 路径数组：OpenFilePanel返回的是字符串数组，即使单选模式也是如此。这是为了兼容多选文件的情况。所以记得取paths[0]。
• Linux依赖：在Linux平台上，它可能依赖外部程序如zenity。你需要确保目标Linux系统安装了这些依赖，或者在游戏发布说明中告知用户。否则文件对话框可能无法弹出或崩溃。
• WebGL与移动平台：这个库不适用于WebGL、Android、iOS。在这些平台上，文件系统访问受到严格限制，必须使用完全不同的策略。

3. 深入系统层：.NET的System.Windows.Forms（仅限Windows）

当你需要比StandaloneFileBrowser更复杂、更定制化的文件对话框时，例如需要预设更复杂的过滤器、调整对话框样式、或与其他Windows窗体控件深度集成时，可以诉诸于.NET框架本身的System.Windows.Forms命名空间。

原理与适用场景System.Windows.Forms是.NET Framework中用于构建Windows桌面应用程序的GUI库。OpenFileDialog和SaveFileDialog是这个库中的两个成熟控件。在Unity的Windows独立平台构建中，你可以使用它们，因为它们依赖于Windows的原生API，与用C#编写的Windows桌面程序完全一样。

基础用法示例：

using System.Windows.Forms; // 需要添加对System.Windows.Forms.dll的程序集引用 using UnityEngine; public class WindowsFileDialogExample : MonoBehaviour { void Start() { // 创建打开文件对话框实例 OpenFileDialog openFileDialog = new OpenFileDialog(); // 配置对话框属性 openFileDialog.Title = "请选择您的数据文件"; openFileDialog.InitialDirectory = @"C:\Users\Public\Documents"; // 初始目录 openFileDialog.Filter = "文本文件 (*.txt)|*.txt|JSON文件 (*.json)|*.json|所有文件 (*.*)|*.*"; openFileDialog.FilterIndex = 2; // 默认选中第二个过滤器（JSON文件） openFileDialog.RestoreDirectory = true; // 关闭对话框后恢复当前目录 // 显示对话框（模态阻塞） DialogResult result = openFileDialog.ShowDialog(); // 处理结果 if (result == DialogResult.OK) // 用户点击了“打开” { string selectedFilePath = openFileDialog.FileName; Debug.Log("选中的文件: " + selectedFilePath); // 在这里进行文件读取操作... } else { Debug.Log("用户取消了选择。"); } // 重要：释放对话框占用的资源 openFileDialog.Dispose(); } }

高级配置与技巧：

• 多选文件：将openFileDialog.Multiselect属性设置为true。用户选择多个文件后，可以通过openFileDialog.FileNames（字符串数组）获取所有文件的路径。
• 自定义过滤器：Filter属性的格式是“描述1|扩展名1|描述2|扩展名2”。竖线|是分隔符。例如“图片文件|*.jpg;*.png|所有文件|*.*”。分号;用于分隔同一描述下的多个扩展名。
• 检查路径有效性：除了检查DialogResult.OK，还应检查FileName是否为空或null。虽然用户点击OK后通常会有文件，但某些边缘情况（如直接输入一个不存在的路径）仍需处理。
• 线程问题：ShowDialog()会阻塞调用它的线程。在Unity中，如果你在主线程（游戏循环线程）上调用它，游戏会卡住，直到对话框关闭。这有时是期望的行为（模态），但如果你不希望卡住，可能需要将文件对话框操作放在单独的线程中，但这会涉及复杂的线程间通信（将路径传回主线程），不推荐新手尝试。

重大限制与警告：

• 仅限Windows平台：这是最核心的限制。System.Windows.Forms依赖于Windows的底层图形界面系统，在macOS、Linux、WebGL、Android、iOS上完全无法工作。如果你为这些平台构建，这段代码会导致编译错误或运行时崩溃。
• 构建配置：在Unity中构建Windows项目时，默认的“Mono”或“IL2CPP”脚本后端通常都包含必要的.NET库。但为了确保System.Windows.Forms可用，你可能需要在Player Settings的“Other Settings”中，确保“API Compatibility Level”设置为.NET Framework（而不是.NET Standard），因为.NET Standard是跨平台子集，不包含Windows.Forms。
• 外观与体验：弹出的对话框是标准的Windows对话框，与你的游戏UI风格可能格格不入。如果你追求极致的UI统一，这可能不是最佳选择。

4. 应对特殊平台：WebGL、移动端与无头环境

对于WebGL、Android、iOS等平台，操作系统级的原生文件对话框要么无法调用，要么行为受到严格限制。在这些场景下，我们需要换一种思路。

4.1 WebGL平台：基于浏览器的上传与下载

在WebGL中，Unity应用运行在浏览器的沙盒环境中，无法直接访问用户的文件系统。所有文件交互都必须通过浏览器提供的HTML5 API进行，本质上是“上传”和“下载”操作。

实现原理：Unity通过C#与JavaScript互操作（JSLib）来调用浏览器的<input type=”file”>元素。当用户点击这个元素时，浏览器会弹出其自身的文件选择窗口。选择文件后，文件数据会传入Unity，但Unity得到的不是文件路径，而是文件的字节数据。你需要在内存中处理这些数据。

常用方法与库：

• UnityWebRequest：可以用于处理上传的文件数据。
• 第三方库：像WebGLFileUploader这样的社区库封装了JSLib的复杂细节，提供了更简单的C#接口。它们通常会创建一个隐藏的<input>元素，触发点击事件，然后通过回调将文件数据（作为byte[]或Texture2D等）传回C#。

示例思路（使用简单JSLib）：

1. 编写一个.jslib文件，暴露一个函数给C#调用，这个函数会创建并点击一个<input type=”file”>。
2. 在C#中，通过[DllImport(“__Internal”)]声明外部函数并调用它。
3. 通过另一个JSLib回调函数，将文件数据（如ArrayBuffer）传递回C#侧。
4. 在C#中，将接收到的数据转换为可用的格式。

保存文件在WebGL中：同样，你不能直接写入本地路径。通常的做法是，将数据（如JSON字符串）转换为一个Blob，然后创建一个隐藏的<a>标签，设置其href为Blob的URL，并触发点击事件，这会提示用户下载一个文件。

核心要点：

• 无路径：忘掉文件路径的概念，一切围绕数据流进行。
• 异步操作：文件选择和数据回调都是异步的，你的代码逻辑需要适应这种模式。
• 安全限制：浏览器禁止脚本自动弹出文件选择框，必须由真实的用户手势（如点击）触发。

4.2 Android与iOS平台：使用原生插件或特定API

移动平台有自己的一套文件访问规则，通常通过分享面板、文档选择器或相册选择器来进行。

• Android：

  • 使用UnityEngine.Android.Permission：首先，你需要动态请求READ_EXTERNAL_STORAGE或WRITE_EXTERNAL_STORAGE权限（取决于Android版本和Target SDK）。
  • 使用UnityEngine.Android：可以通过AndroidJavaClass和AndroidJavaObject调用Android的Intent来启动系统的文件选择器或文档选择器。这相当复杂，需要熟悉Android的Intent机制。
  • 使用第三方插件：许多Asset Store插件（如Native File Picker、Mobile File Browser）封装了这些原生调用，提供了统一的C#接口，是更高效的选择。

• iOS：

  • 权限：需要在Info.plist中添加相册或文件访问的使用描述。
  • 原生调用：同样需要通过[DllImport(“__Internal”)]调用Objective-C代码来弹出系统的UIDocumentPickerViewController。
  • 推荐插件：由于iOS审核严格且API变动，强烈建议使用成熟的第三方插件来处理文件选择，它们会处理好所有兼容性和权限问题。

移动端的共同特点：

• 沙盒访问：应用通常只能直接访问自己的沙盒目录（Application.persistentDataPath）。访问外部共享存储（如DCIM、Downloads）需要用户通过系统选择器显式授权。
• 无绝对路径：即使你通过选择器拿到了一个文件的“URI”或“URL”，它也可能不是一个可以直接用System.IO.File打开的路径。你需要使用Unity的UnityWebRequest或插件提供的方法来读取其内容。

4.3 无头模式或服务器环境

如果你的Unity程序运行在服务器（如使用Unity进行后台渲染、数据处理）或无头模式（Headless）下，根本没有图形界面，那么所有基于GUI的对话框都无法使用。

解决方案：

• 命令行参数：最常见的做法。在启动程序时，通过命令行参数传入文件或目录的路径。例如：MyUnityApp.exe -input “C:\data\input.json” -output “D:\results\”。在Unity中，使用System.Environment.GetCommandLineArgs()来获取并解析这些参数。
• 配置文件：程序从一个预定义的配置文件（如config.json）中读取输入输出路径。配置文件可以放在程序旁边或一个固定位置。
• 网络接口：程序启动后，监听一个本地网络端口（如HTTP端口），等待外部工具或脚本向其发送包含文件数据的请求。这种方式更灵活，适合自动化流水线。

5. 实战整合与架构设计

了解了各种方法后，如何在实际项目中优雅地整合它们呢？关键在于抽象和平台依赖编译。

5.1 创建统一的文件对话框接口

首先，定义一个接口，抽象出文件对话框的核心操作：

public interface IFileDialogService { string OpenFile(string title, string directory, string extension); string[] OpenFiles(string title, string directory, string extension, bool multiselect); string OpenFolder(string title, string directory); string SaveFile(string title, string directory, string defaultName, string extension); }

5.2 为不同平台实现接口

然后，为不同的运行时环境提供具体实现：

1. 编辑器实现 (使用EditorUtility)：

#if UNITY_EDITOR using UnityEditor; public class EditorFileDialogService : IFileDialogService { public string OpenFile(string title, string directory, string extension) { return EditorUtility.OpenFilePanel(title, directory, extension); } // ... 实现其他方法，内部调用EditorUtility对应方法 } #endif

2. Windows/Mac/Linux独立平台实现 (使用StandaloneFileBrowser)：

#if !UNITY_EDITOR && (UNITY_STANDALONE_WIN || UNITY_STANDALONE_OSX || UNITY_STANDALONE_LINUX) using SFB; public class StandaloneFileDialogService : IFileDialogService { public string OpenFile(string title, string directory, string extension) { var extensions = string.IsNullOrEmpty(extension) ? null : new [] { new ExtensionFilter("Files", extension.Split(',')) }; var paths = StandaloneFileBrowser.OpenFilePanel(title, directory, extensions, false); return paths.Length > 0 ? paths[0] : string.Empty; } // ... 实现其他方法 } #endif

3. WebGL平台实现 (使用JSLib/第三方库)：

#if !UNITY_EDITOR && UNITY_WEBGL public class WebGLFileDialogService : IFileDialogService { // WebGL无法同步返回路径，接口需要设计为异步回调式 public void OpenFileAsync(string title, string directory, string extension, System.Action<string, byte[]> onFileSelected) { // 调用封装的JSLib，触发浏览器文件选择 // 在JSLib的回调中，将文件数据作为byte[]传回，并调用onFileSelected(null, fileData) // 注意：第一个参数（路径）在WebGL中通常为null或一个虚拟路径 } // 为了兼容同步接口，可以抛出不支持异常或返回空 public string OpenFile(string title, string directory, string extension) { Debug.LogError("同步文件选择在WebGL中不支持，请使用异步方法。"); return string.Empty; } } #endif

4. 移动平台实现 (使用原生插件接口)：

#if !UNITY_EDITOR && (UNITY_IOS || UNITY_ANDROID) public class MobileFileDialogService : IFileDialogService { // 调用Native File Picker等插件的API // 同样，移动端多为异步回调模式 } #endif

5.3 使用工厂模式或依赖注入提供实例

在游戏启动或需要的地方，根据平台条件实例化对应的服务：

public class FileDialogProvider { public static IFileDialogService GetService() { #if UNITY_EDITOR return new EditorFileDialogService(); #elif UNITY_STANDALONE_WIN || UNITY_STANDALONE_OSX || UNITY_STANDALONE_LINUX return new StandaloneFileDialogService(); #elif UNITY_WEBGL return new WebGLFileDialogService(); #elif UNITY_IOS || UNITY_ANDROID return new MobileFileDialogService(); #else // 回退到一个基于命令行或配置文件的简单实现，或无操作实现 return new DummyFileDialogService(); #endif } }

这样，在你的游戏逻辑中，你只需要调用FileDialogProvider.GetService().OpenFile(...)，而无需关心底层是哪个平台、用了哪种技术。这种架构极大地提高了代码的可维护性和可移植性。

6. 高级话题：自定义UI与拖拽支持

有时，系统原生的文件对话框在风格上可能与你的游戏UI严重不搭，或者你需要更复杂的交互（如预览、批量操作）。这时，可以考虑完全自己实现一个文件浏览器UI。

6.1 使用Unity UI构建自定义文件浏览器

这需要你利用System.IO命名空间中的类（Directory,DirectoryInfo,FileInfo,Path）来遍历目录、获取文件信息，然后用UGUI（如Button,Image,Text,ScrollView）来构建列表和图标。

核心步骤：

1. 获取驱动器与目录列表：使用Directory.GetLogicalDrives()（仅Windows）或从某个根目录（如Application.dataPath的上级）开始，用Directory.GetDirectories(path)获取子文件夹。
2. 获取文件列表：使用Directory.GetFiles(path, searchPattern)获取当前目录下的文件。searchPattern可以是“*.png”或“*.*”。
3. UI渲染：为每个目录和文件创建一个UI项（Prefab），显示名称、图标（可以根据扩展名映射）、大小、修改日期等信息。
4. 导航：点击目录项，更新当前路径，重新获取列表并刷新UI。需要实现“返回上级”按钮。
5. 选择与确认：管理选中的文件/文件夹，提供“打开”或“选择”按钮。

优点：

• 完全可控：UI风格、交互逻辑、过滤规则完全自定义。
• 无缝集成：与游戏其他UI部分完美融合。

缺点：

• 开发量大：需要处理所有UI逻辑、排序、过滤、图标管理、路径历史（前进/后退）等。
• 性能：如果目录下文件极多，需要做虚拟化列表优化，防止UI卡顿。
• 功能局限：难以实现系统级功能，如网络位置、库（如Windows的“图片库”、“文档库”）、快捷方式解析等。

6.2 实现拖拽功能

对于PC游戏，支持将文件从系统资源管理器直接拖拽到游戏窗口是一个提升用户体验的亮点功能。Unity提供了EventSystem来处理拖拽。

基本原理：

1. 在需要接受拖拽的UI元素（如一个Image或整个面板）上挂载脚本。
2. 在Update方法中，监听Input或通过EventSystem.current检查拖拽事件。
3. 使用UnityEngine.DragAndDrop类（在编辑器脚本中更常用）或直接处理EventSystem的拖拽事件来获取拖拽物的路径信息。

示例代码片段：

using UnityEngine; using UnityEngine.EventSystems; public class FileDropHandler : MonoBehaviour, IDropHandler { public void OnDrop(PointerEventData eventData) { // 检查是否有拖拽的文件 if (DragAndDrop.paths != null && DragAndDrop.paths.Length > 0) { string droppedFilePath = DragAndDrop.paths[0]; Debug.Log("拖拽的文件路径: " + droppedFilePath); // 验证文件类型、读取内容等... } } }

注意：DragAndDrop类在运行时（非编辑器）的行为可能有限。更可靠的方法是在Update中检查Input.GetMouseButton(0)并结合EventSystem.current.IsPointerOverGameObject()来判断，然后尝试从系统剪贴板或通过平台特定API获取拖拽信息。在Windows上，这可能需要调用一些Win32 API，复杂度较高，可以考虑使用专门的插件。

7. 性能、兼容性与调试技巧

在文件对话框的使用中，还有一些细节问题需要注意。

性能考量：

• 频繁调用：避免在每帧（Update）中调用文件对话框API。它们是阻塞式调用，会卡住主线程。
• 大文件处理：无论是通过哪种方式获取到文件路径，在读取大文件（如高清视频、大型数据包）时，一定要使用异步读取（如File.ReadAllBytesAsync在.NET 4.x+，或使用Thread/Task），避免游戏卡顿。
• 路径缓存：如果用户经常从同一目录操作文件，可以将最后一次使用的路径保存到PlayerPrefs中，下次打开对话框时作为初始目录，提升用户体验。

兼容性陷阱：

• 路径分隔符：Windows使用反斜杠\，而macOS/Linux使用正斜杠/。始终使用System.IO.Path.Combine()来拼接路径，使用Path.DirectorySeparatorChar来获取当前平台的正确分隔符。不要自己硬编码“/”或“\”。
• 文件名非法字符：不同操作系统对文件名中非法字符的规定略有不同。使用Path.GetInvalidFileNameChars()和Path.GetInvalidPathChars()来检查或清理用户输入的文件名。
• 大小写敏感：Windows文件系统通常不区分大小写，而macOS（APFS分区）和Linux区分。如果你的游戏涉及按文件名查找资源，最好使用统一的大小写转换（如ToLowerInvariant()）进行比较。

调试技巧：

• 日志输出：在调用文件对话框前后，以及获取到路径后，使用Debug.Log输出完整的路径和操作结果。这在排查“为什么没找到文件”时非常有用。
• 权限检查：在尝试读写文件前，可以使用File.Exists(path)检查文件是否存在，使用Directory.Exists(Path.GetDirectoryName(path))检查目录是否存在。对于写操作，还可以尝试用File.OpenWrite（在using语句中）来测试是否有写入权限，并及时捕获UnauthorizedAccessException异常。
• 编辑器与运行时差异：在编辑器中测试时，路径基准（如Application.dataPath）是项目目录。而在打包后的游戏中，Application.dataPath指向游戏的数据文件夹（只读）。Application.persistentDataPath才是可写的玩家数据目录。务必注意这个区别，保存玩家数据时一定要用persistentDataPath。