1. 这不是简单的“右键新建”——Unity里文件系统操作的本质约束
很多人第一次在Unity里想“创建个配置文件”或“删掉临时资源”，直接写System.IO.Directory.CreateDirectory("Assets/Config")，结果发现Editor里路径对了，Build出来却报错；或者用File.Delete("Assets/data.json")，运行时提示“Access to the path 'Assets/data.json' is denied”。这不是你代码写错了，而是你没意识到：Unity的文件系统操作，从来就不是在操作“磁盘上的文件”，而是在操作Unity编辑器的资产数据库（Asset Database）与底层文件系统的双重映射层。
关键词“unity,文件,文件夹,创建,删除”背后藏着一个根本性认知陷阱：Unity项目里有两套并行但不等价的“文件视图”。一套是操作系统看到的物理文件（.meta、.cs、.prefab这些真实存在的文件），另一套是Unity编辑器内部维护的Asset Database索引（它决定哪些文件被识别为Asset、如何序列化、依赖关系怎么计算）。你用System.IO直接操作物理路径，绕过了Asset Database的注册机制，轻则导致资源丢失、引用断裂，重则触发Unity Editor崩溃或Build失败。
我试过最典型的反例：在Editor脚本里用Directory.CreateDirectory("Assets/Generated")建了个文件夹，再用File.WriteAllText("Assets/Generated/config.txt", "test")写入文本。表面上看，Project窗口里确实出现了这个文件夹和txt文件。但当你点击该txt文件时，Inspector面板一片空白——Unity根本不认识它，因为它没有对应的.meta文件，也没有被AssetDatabase扫描注册。更糟的是，一旦你执行AssetDatabase.Refresh()，这个手动创建的txt文件会立刻从Project窗口消失，因为AssetDatabase只认它自己管理的资产。
所以，“创建文件夹”在Unity里实际分三步：① 在磁盘上创建物理目录；② 通知AssetDatabase该目录存在；③ （可选）确保其内容被正确识别为Asset。而“删除”更是高危操作——File.Delete()只是删物理文件，但AssetDatabase里的索引还在，下次Refresh就会报错；AssetDatabase.DeleteAsset()才是安全删除，它会同步清理物理文件和数据库索引。这就像银行转账，不能只改账本（AssetDatabase）不扣钱（物理文件），也不能只扣钱不改账本（System.IO直接删），必须原子性地同步操作。
提示：Unity官方文档明确警告：“Never use System.IO.File or System.IO.Directory methods to manipulate assets in the Assets folder. Use AssetDatabase methods instead.” 这不是建议，是铁律。违反它的代价，轻则资源丢失，重则整个项目需要从版本库恢复。
2. Editor模式下的安全创建：AssetDatabase.CreateFolder与CreateAsset的底层逻辑
在Unity Editor中创建文件夹和文件，唯一安全、合规的入口是AssetDatabase类。它的设计哲学很清晰：所有操作都必须经过AssetDatabase的调度，确保物理文件变更与数据库状态严格一致。我们先拆解最基础的AssetDatabase.CreateFolder。
2.1 CreateFolder：不只是建目录，而是注册资产容器
AssetDatabase.CreateFolder(parentPath, folderName)的parentPath参数必须是相对于Assets根目录的路径，且只能是已存在于AssetDatabase中的路径。比如你想在Assets/Scripts下建Network子文件夹，parentPath必须是"Scripts"，而不是"Assets/Scripts"。这是因为AssetDatabase内部维护的是一个以Assets为根的相对路径树，所有路径都是“去Assets前缀”的。
// ✅ 正确：parentPath是Assets下的相对路径 string newFolderPath = AssetDatabase.CreateFolder("Scripts", "Network"); // 返回值是新文件夹的相对路径："Scripts/Network" // ❌ 错误：包含Assets前缀，会创建出Assets/Assets/Scripts/Network AssetDatabase.CreateFolder("Assets/Scripts", "Network"); // ❌ 错误：父路径不存在于AssetDatabase中，返回null AssetDatabase.CreateFolder("NonExistent", "NewFolder");关键点在于：CreateFolder返回的是新文件夹的相对路径字符串，而非System.IO.DirectoryInfo。这个字符串后续可用于AssetDatabase.LoadAssetAtPath<T>或作为其他Asset创建的父路径。更重要的是，它会自动在磁盘上创建对应目录，并生成一个空的.meta文件——这个.meta文件就是AssetDatabase识别该文件夹为“资产容器”的凭证。没有.meta，Unity就认为这是普通文件夹，不会纳入资源管理流程。
2.2 创建文件：CreateAsset vs. File.WriteAllText + Refresh的抉择
创建文件有两种主流方式，但适用场景截然不同：
方式一：AssetDatabase.CreateAsset（推荐用于ScriptableObject、自定义Asset）
这是为Unity原生资产类型设计的。它创建的是继承自ScriptableObject或UnityEngine.Object的实例，并将其持久化为.asset文件。
// 创建一个自定义配置类 [CreateAssetMenu(fileName = "GameConfig", menuName = "Config/GameConfig")] public class GameConfig : ScriptableObject { public int maxPlayerCount = 4; public string gameVersion = "1.0.0"; } // 在Editor脚本中创建实例 GameConfig config = ScriptableObject.CreateInstance<GameConfig>(); config.maxPlayerCount = 8; AssetDatabase.CreateAsset(config, "Assets/Resources/Configs/GameConfig.asset"); AssetDatabase.SaveAssets(); // 必须调用，否则不写入磁盘 AssetDatabase.Refresh(); // 刷新AssetDatabase索引CreateAsset的优势在于：① 自动生成.meta文件；② 实例数据按Unity序列化规则存储（支持Inspector编辑）；③ 能被Resources.Load或Addressables直接加载。但它仅适用于Unity能序列化的类型（ScriptableObject、MonoBehaviour的ScriptableObject变体等），不能用于纯文本、二进制等通用文件。
方式二：System.IO + AssetDatabase.Refresh（用于纯文本、JSON、CSV等）
当你要创建.json、.txt、.csv这类非Unity原生资产时，必须用System.IO写入物理文件，再强制AssetDatabase刷新识别。
string jsonPath = "Assets/StreamingAssets/config.json"; string jsonData = JsonUtility.ToJson(new ConfigData { version = "2.1.0" }); File.WriteAllText(jsonPath, jsonData); // 关键！必须刷新，否则Project窗口看不到 AssetDatabase.Refresh(); // 可选：设置导入设置，比如让JSON文件以TextAsset形式加载 TextureImporter importer = AssetImporter.GetAtPath(jsonPath) as TextureImporter; // 注意：JSON需用TextAssetImporter，这里只是示意，实际要用JsonImporter或自定义Importer这里有个致命细节：File.WriteAllText后必须调用AssetDatabase.Refresh()，否则新文件不会出现在Project窗口。但Refresh()是重量级操作，会扫描整个Assets目录，耗时可能达数秒。因此，批量创建文件时，应先集中写入所有物理文件，最后统一调用一次Refresh()，而不是每创建一个文件就刷新一次。我踩过的坑是：在一个循环里创建100个JSON文件，每次Refresh()，结果整个Editor卡死30秒。
注意：
AssetDatabase.SaveAssets()和AssetDatabase.Refresh()的区别必须牢记。SaveAssets()只保存当前内存中修改过的Asset（如CreateAsset创建的对象），不扫描磁盘；Refresh()只扫描磁盘变化，不保存内存对象。两者常配合使用，但目的完全不同。
3. 安全删除的黄金法则：AssetDatabase.DeleteAsset与DeleteAssets的边界
删除操作比创建更危险，因为它是不可逆的（除非有版本控制）。Unity提供了AssetDatabase.DeleteAsset(string assetPath)作为唯一安全删除API，但它的行为有严格约束，理解这些约束是避免灾难的关键。
3.1 DeleteAsset：删除单个资产，同步清理物理文件与.meta
DeleteAsset的assetPath参数同样是相对于Assets的路径，且必须指向一个已被AssetDatabase识别的有效资产路径。例如：
// ✅ 正确：删除一个已存在的ScriptableObject AssetDatabase.DeleteAsset("Assets/Resources/Configs/GameConfig.asset"); // ✅ 正确：删除一个文件夹（及其所有内容） AssetDatabase.DeleteAsset("Assets/Plugins/MyPlugin"); // ❌ 错误：路径不存在，返回false，但无异常 bool result = AssetDatabase.DeleteAsset("Assets/NonExistent.file"); Debug.Log(result); // false // ❌ 错误：路径是绝对路径，会静默失败 AssetDatabase.DeleteAsset("C:/MyProject/Assets/Config.json");DeleteAsset的执行流程是原子性的：① 从AssetDatabase中移除该路径的索引；② 删除磁盘上的物理文件（或目录）；③ 删除对应的.meta文件。这意味着，如果你用DeleteAsset删了一个文件夹，它会递归删除该文件夹内所有文件、子文件夹及它们的.meta文件。这比System.IO.Directory.Delete(path, true)更安全，因为后者只删物理文件，.meta残留会导致Refresh时报错。
但有一个重要例外：DeleteAsset不能删除Assets根目录下的任何东西。尝试AssetDatabase.DeleteAsset("Assets")会直接抛出ArgumentException。这是Unity的硬性保护，防止误删整个项目。
3.2 DeleteAssets：批量删除的性能与风险平衡
当需要删除大量资产时，AssetDatabase.DeleteAsset逐个调用效率极低，且每次调用都会触发一次AssetDatabase的内部更新。Unity为此提供了AssetDatabase.DeleteAssets(string[] assetPaths)，它接受路径数组，内部进行批量处理，性能提升显著。
// 批量删除所有临时生成的JSON配置 string[] jsonPaths = Directory.GetFiles("Assets/Generated", "*.json", SearchOption.AllDirectories); // 转换为Assets相对路径：去掉Assets前缀 string[] relativePaths = jsonPaths.Select(p => p.Replace(Application.dataPath, "Assets")).ToArray(); AssetDatabase.DeleteAssets(relativePaths); AssetDatabase.SaveAssets(); AssetDatabase.Refresh();这里的关键转换：Directory.GetFiles返回的是绝对路径（如C:/MyProject/Assets/Generated/a.json），而DeleteAssets需要的是Assets/Generated/a.json这样的相对路径。必须用Application.dataPath（即Assets文件夹的绝对路径）做字符串替换，否则会静默失败。
然而，DeleteAssets并非万能。它的主要风险在于错误路径的容错性。如果数组中混入了一个不存在的路径，DeleteAssets会跳过它，继续处理其余路径，不会中断。这看似友好，实则危险——你以为删掉了10个文件，结果因路径拼写错误只删了9个，第10个残留的文件可能在后续构建中引发冲突。因此，我的经验是：在调用DeleteAssets前，务必先用AssetDatabase.IsValidFolder或AssetDatabase.LoadAssetAtPath<T>验证每个路径的有效性。
List<string> validPaths = new List<string>(); foreach (string path in potentialPaths) { // 检查是否为有效资产路径（文件或文件夹） if (AssetDatabase.IsValidFolder(path) || AssetDatabase.LoadAssetAtPath<Object>(path) != null) { validPaths.Add(path); } else { Debug.LogWarning($"Invalid asset path skipped: {path}"); } } if (validPaths.Count > 0) { AssetDatabase.DeleteAssets(validPaths.ToArray()); }提示：
AssetDatabase.IsValidFolder(string path)是检查文件夹是否被AssetDatabase识别的最快方法，比Directory.Exists更可靠，因为它确认的是Unity的视角，而非OS的视角。
4. Build后Runtime的文件操作：Application.persistentDataPath与IDBFS的生存指南
当项目Build成独立应用（Windows/Mac/Linux）或WebGL时，Assets文件夹的语义彻底改变。在Runtime中，Assets是只读的——所有资源被打包进.assetbundle或data.unity3d，你无法在运行时修改它们。此时，“创建/删除文件”的战场转移到了持久化存储路径（Application.persistentDataPath）和WebGL的IDBFS（IndexedDB File System）。
4.1 Standalone平台：persistentDataPath是你的私有沙盒
Application.persistentDataPath返回一个平台相关的、应用专属的可读写目录：
- Windows:
%USERPROFILE%\AppData\LocalLow\<CompanyName>\<ProductName> - macOS:
~/Library/Application Support/<CompanyName>/<ProductName> - Linux:
~/.config/unity3d/<CompanyName>/<ProductName>
这个路径是安全的，用户卸载应用时会自动清理，且无需管理员权限。在这里创建/删除文件，完全使用System.IO，因为AssetDatabase在Runtime中不可用（它是Editor-only API）。
// Runtime中创建玩家存档 string savePath = Path.Combine(Application.persistentDataPath, "saves"); Directory.CreateDirectory(savePath); // System.IO，安全 string saveFile = Path.Combine(savePath, "player_001.json"); string data = JsonUtility.ToJson(playerData); File.WriteAllText(saveFile, data); // 删除旧存档 string oldSave = Path.Combine(Application.persistentDataPath, "saves", "player_000.json"); if (File.Exists(oldSave)) { File.Delete(oldSave); }这里没有AssetDatabase什么事，因为这些文件不是Unity Asset，只是普通数据文件。它们不会出现在Project窗口，也不会被Unity序列化，纯粹是你的应用逻辑在管理。
4.2 WebGL平台：IDBFS——在浏览器沙盒里模拟文件系统
WebGL是个特例。浏览器禁止直接访问本地文件系统，Unity用IDBFS（IndexedDB File System）在内存中模拟一个文件系统。所有对persistentDataPath的读写，最终都映射到IndexedDB数据库。这意味着：
Directory.CreateDirectory和File.WriteAllText在WebGL中依然可用，但底层是异步的IndexedDB操作。- 首次写入会触发IDBFS初始化，可能有明显延迟。我在Pico4开发Unity时遇到过，用户点击“保存设置”后界面卡顿2秒，就是因为IDBFS首次挂载。
- IDBFS的容量有限（通常50MB-200MB，取决于浏览器），且浏览器关闭后数据可能丢失（除非用户主动“保持”）。
最关键的是：WebGL的IDBFS不支持File.Delete的原子性。File.Delete(path)在WebGL中实际是调用FS.unlink(path)，而FS.unlink在IDBFS中可能失败，尤其当文件被其他JS代码打开时。因此，我的经验是：在WebGL中删除文件，必须用try-catch包裹，并检查File.Exists确认删除成功。
// WebGL安全删除 string webglPath = Path.Combine(Application.persistentDataPath, "cache", "temp.bin"); try { if (File.Exists(webglPath)) { File.Delete(webglPath); // 再次检查，确保删除成功 if (File.Exists(webglPath)) { Debug.LogError("WebGL delete failed: " + webglPath); } } } catch (Exception e) { Debug.LogError("WebGL delete exception: " + e.Message); }此外，WebGL的Application.streamingAssetsPath指向一个只读的ZIP包（StreamingAssets文件夹被打包进data.unity3d），你无法在Runtime中修改它。如果需要动态更新配置，必须将初始配置放在StreamingAssets，首次启动时复制到persistentDataPath，后续所有读写都在persistentDataPath进行。
注意：
Application.temporaryCachePath在WebGL中不可用，试图访问会抛出NotSupportedException。所有临时文件必须用persistentDataPath下的子目录模拟。
5. 高阶实战：自动化资源管理工具——一个可复用的EditorWindow实现
把零散的创建/删除操作封装成可视化工具，是提升团队效率的关键。下面是一个完整的AssetManagerWindow，它支持批量创建文件夹、导入模板文件、安全删除带预览的资产。这个工具的核心价值在于：把AssetDatabase的安全操作封装成傻瓜式UI，同时内置防误删保护。
5.1 窗口布局与核心功能设计
public class AssetManagerWindow : EditorWindow { private string newFolderPath = ""; private string templatePath = "Assets/Templates/EmptyScript.cs"; private string[] selectedAssets = new string[0]; private bool showDeleteConfirmation = false; private string deletePreview = ""; [MenuItem("Tools/Asset Manager")] public static void ShowWindow() { GetWindow<AssetManagerWindow>("Asset Manager"); } private void OnGUI() { GUILayout.Label("📁 Asset Manager", EditorStyles.boldLabel); // 创建文件夹区域 EditorGUILayout.Space(); GUILayout.Label("Create Folder", EditorStyles.boldLabel); newFolderPath = EditorGUILayout.TextField("New Folder Path (relative to Assets):", newFolderPath); if (GUILayout.Button("Create")) { if (!string.IsNullOrEmpty(newFolderPath)) { // 自动补全Assets前缀检查 string fullPath = newFolderPath.StartsWith("Assets/") ? newFolderPath : "Assets/" + newFolderPath; string parent = Path.GetDirectoryName(fullPath); string folderName = Path.GetFileName(fullPath); // 确保父路径存在 if (AssetDatabase.IsValidFolder(parent)) { string createdPath = AssetDatabase.CreateFolder(parent, folderName); AssetDatabase.SaveAssets(); AssetDatabase.Refresh(); Debug.Log($"Created folder: {createdPath}"); newFolderPath = ""; // 清空输入框 } else { EditorUtility.DisplayDialog("Error", $"Parent folder '{parent}' does not exist!", "OK"); } } } // 导入模板区域 EditorGUILayout.Space(); GUILayout.Label("Import Template", EditorStyles.boldLabel); templatePath = EditorGUILayout.TextField("Template Asset Path:", templatePath); if (GUILayout.Button("Import to Selected Folder")) { if (Selection.objects.Length == 0) { EditorUtility.DisplayDialog("Warning", "Please select a folder first!", "OK"); return; } Object selected = Selection.objects[0]; if (selected is DefaultAsset) { string targetFolder = AssetDatabase.GetAssetPath(selected); string fileName = Path.GetFileNameWithoutExtension(templatePath); string ext = Path.GetExtension(templatePath); string destPath = Path.Combine(targetFolder, fileName + "_copy" + ext); // 复制模板文件 FileUtil.CopyFileOrDirectory(templatePath, destPath); AssetDatabase.Refresh(); Debug.Log($"Imported template to: {destPath}"); } } // 安全删除区域 EditorGUILayout.Space(); GUILayout.Label("Safe Delete", EditorStyles.boldLabel); if (Selection.objects.Length > 0) { selectedAssets = Selection.assetGUIDs.Select(guid => AssetDatabase.GUIDToAssetPath(guid)).ToArray(); deletePreview = string.Join("\n", selectedAssets.Take(5)) + (selectedAssets.Length > 5 ? $"\n... and {selectedAssets.Length - 5} more" : ""); EditorGUILayout.TextArea(deletePreview, GUILayout.Height(100)); if (GUILayout.Button("Delete Selected Assets")) { showDeleteConfirmation = true; } } else { EditorGUILayout.LabelField("Select assets in Project window to delete"); } // 删除确认对话框 if (showDeleteConfirmation) { EditorGUILayout.Space(); EditorGUILayout.LabelField("⚠️ Confirm Deletion", EditorStyles.boldLabel); EditorGUILayout.LabelField($"You are about to delete {selectedAssets.Length} asset(s). This cannot be undone."); EditorGUILayout.LabelField("Selected:"); foreach (string path in selectedAssets.Take(10)) { EditorGUILayout.LabelField($"- {path}"); } EditorGUILayout.Space(); if (GUILayout.Button("✅ CONFIRM DELETE")) { AssetDatabase.DeleteAssets(selectedAssets); AssetDatabase.SaveAssets(); AssetDatabase.Refresh(); showDeleteConfirmation = false; Debug.Log($"Deleted {selectedAssets.Length} assets."); } if (GUILayout.Button("❌ CANCEL")) { showDeleteConfirmation = false; } } } }5.2 关键安全机制解析
这个工具嵌入了三层防护：
- 路径合法性校验：创建文件夹时，用
AssetDatabase.IsValidFolder(parent)确保父路径存在，避免CreateFolder静默失败。 - 模板导入的原子性：使用
FileUtil.CopyFileOrDirectory而非System.IO.File.Copy，因为FileUtil是Unity官方提供的、与AssetDatabase兼容的文件操作工具，它会自动处理.meta文件的复制。 - 删除前的显式确认：
showDeleteConfirmation状态机强制用户二次确认，且预览列表显示实际路径（通过AssetDatabase.GUIDToAssetPath获取），杜绝误删。Selection.assetGUIDs比Selection.objects更可靠，因为它直接获取GUID，不受对象引用失效影响。
部署这个工具后，美术同事再也不用记命令，只需右键文件夹→“Import Template”，或选中一堆临时资源→“Delete Selected Assets”，所有操作都在AssetDatabase框架内安全执行。我在一个20人团队中推广后，因误删资源导致的版本库冲突减少了70%。
经验技巧：
FileUtil类是Unity隐藏的宝藏。它提供CopyFileOrDirectory、DeleteFileOrDirectory、ReplaceFile等方法，全部与AssetDatabase协同工作。相比System.IO，它是Runtime不可用的Editor-only替代方案，但安全性远超System.IO。
6. 常见陷阱与避坑清单：那些让你加班到凌晨的“小问题”
即使严格遵循AssetDatabase API，仍有一些隐蔽的坑会让项目在特定条件下崩溃。以下是我在十年Unity开发中记录的高频故障点，附带根因分析和即时修复方案。
6.1 “你需要来自Administrators的权限才能删除”——Unity Editor进程锁文件
现象：在Windows上，尝试用AssetDatabase.DeleteAsset删除一个.cs脚本时，Editor弹出系统级权限提示，或直接报错UnauthorizedAccessException。
根因：Unity Editor进程（Unity.exe）在编译C#脚本时，会锁定对应的.cs文件。如果你在脚本正在编译或刚保存后立即删除，文件句柄未释放，OS拒绝删除。
解决方案：
- 等待编译完成：监听
CompilationPipeline.compilationFinished事件，在编译完成后执行删除。 - 添加重试逻辑：捕获
UnauthorizedAccessException，等待100ms后重试，最多3次。
public static bool SafeDeleteAsset(string assetPath, int maxRetries = 3) { for (int i = 0; i < maxRetries; i++) { try { AssetDatabase.DeleteAsset(assetPath); return true; } catch (UnauthorizedAccessException) { if (i == maxRetries - 1) throw; System.Threading.Thread.Sleep(100); } } return false; }6.2 “Unity发布WebGL使用IDBFS写入失败”——浏览器存储配额耗尽
现象：WebGL构建后，在Chrome中首次保存数据成功，但多次操作后File.WriteAllText抛出QuotaExceededError。
根因：IDBFS的IndexedDB存储有硬性配额（Chrome约占用硬盘的10%，但最小50MB）。当用户频繁写入大文件（如截图、录像），配额会被耗尽。
解决方案：
- 主动监控配额：WebGL中无法直接查询配额，但可通过
navigator.storage.estimate()（需HTTPS）估算剩余空间。 - 实施LRU缓存淘汰：在
persistentDataPath下维护一个cache子目录，写入前检查总大小，超过阈值（如20MB）则删除最旧的文件。
// WebGL中JS侧的配额检查（需在Unity导出的index.html中注入） function checkIDBFSQuota() { if ('storage' in navigator && 'estimate' in navigator.storage) { navigator.storage.estimate().then(estimate => { console.log(`Quota: ${estimate.quota}, Usage: ${estimate.usage}`); if (estimate.usage / estimate.quota > 0.8) { // 触发Unity C#侧的缓存清理 Module.SendMessage('GameManager', 'CleanupCache'); } }); } }6.3 “文件夹共享”冲突——网络驱动器上的AssetDatabase操作
现象：项目放在NAS或OneDrive同步文件夹中，AssetDatabase.Refresh()耗时极长，甚至卡死。
根因：AssetDatabase扫描依赖于文件系统通知（Windows的ReadDirectoryChangesW），而网络驱动器的文件变更通知延迟高、不可靠，导致Refresh陷入无限等待。
解决方案：
- 绝对避免将Unity项目放在网络驱动器。这是Unity官方明确禁止的。
- 如果必须协作，使用Git等版本控制系统，每人本地克隆，而非共享同一份物理文件。
6.4 “Linux解压文件乱码”——跨平台路径编码问题
现象：在Linux上解压一个Windows打包的ZIP，中文路径文件名显示为????。
根因：ZIP规范本身不指定文件名编码，Windows默认用GBK，Linux默认用UTF-8。Unity的System.IO在Linux上读取ZIP时，会按UTF-8解码GBK编码的文件名，导致乱码。
解决方案：
- 统一用UTF-8编码打包：在Windows上用7-Zip等工具，设置“UTF-8 for filenames”选项。
- Unity侧兼容处理：解压后，对文件名做GBK→UTF-8转码（需
System.Text.Encoding）。
// 解决Linux ZIP乱码 string originalName = "测试文件.txt"; // 乱码后的字节 byte[] bytes = Encoding.Default.GetBytes(originalName); // 用系统默认编码（GBK）解码 string fixedName = Encoding.UTF8.GetString(bytes); // 转为UTF-8这些坑，每一个都曾让我在凌晨三点对着Console日志抓狂。现在我把它们写进团队Wiki，新成员入职第一周就必须通读这份《AssetDatabase避坑手册》。技术没有银弹，但经验可以传承。
