先说一个很多 Unity 开发者都经历过的场景打开工程后Project 窗口里一排排都是 New Material、Cube(1)、Cube(2)、New Texture、Sphere_4、TextMesh Pro 这样的资源名。名字完全不带业务信息时间一长根本分不清哪个是主角的材质哪个是废弃的测试贴图。更麻烦的是这类命名问题不仅影响个人开发效率还会在团队协作、自动化构建、资源管理和后续迭代中持续制造成本。本文就围绕 Unity 资源命名这个话题梳理一套可以落地的命名规范、常见踩坑点以及如何用 Editor 扩展工具批量检查和修正命名。需要说明的是Unity 并不会因为资源名叫 Cube(1) 而报错游戏也能正常跑起来。但“能跑”和“好维护”是两个完全不同的标准。面向长期迭代的项目资源命名越早规范化后期改造成本越低。1. 为什么 Unity 资源命名值得专门写一篇教程1.1 “Cube(1)”“New Material”是怎么冒出来的很多人以为 Cube(1)、New Material(1) 是 Unity 出了 bug其实这是 Unity 的“默认命名机制”在起作用。当你在 Hierarchy 窗口创建一个 3D Object 时Unity 会默认给它起名为 Cube、Sphere、Capsule。当你再次拖入同一模型或在场景里复制对象时Unity 为了区分两个同名对象就会自动追加 (1)、(2) 序号后缀。同样在 Project 窗口通过 Assets Create Material 创建材质时默认名字是 New Material复制一次就变成 New Material (1)。这些名字本身没有错但问题在于它们不带任何语义信息。一个叫 Cube(1) 的模型你无法判断它是环境障碍物、角色占位符还是测试物体。一个叫 New Material 的材质你无法判断它是金属、布料还是皮肤的材质球。Unity 只是按“避免重名”的最低标准在命名它不会替你想业务含义。1.2 命名混乱会带来哪些实际成本资源命名的混乱会在下面几个层面持续消耗开发效率。第一是查找成本。项目迭代到中后期Assets 目录下可能有大几千个资源。如果没有稳定的命名规则想找一个角色贴图就只能一个个预览、一个个点开看导入设置。这种时间消耗是每天都存在的累积起来相当可观。第二是协作成本。团队多人开发时A 同学创建的材质叫 New MaterialB 同学创建的材质也叫 New Material两人又各自在场景里引用了自己的版本。合并场景或清理资源时根本无法快速分辨哪个保留、哪个废弃最终结果往往是“两个都不敢删”。第三是自动化成本。Unity 里很多自动化流程依赖字符串路径或资源地址比如 Resources.Load、AssetBundle 构建、Addressables 的地址映射、Editor 批量处理脚本。如果资源名里带着空格、中文括号、数字开头这类特殊情况命令行构建、跨平台同步、外部工具链处理时都容易出问题。第四是调试成本。当游戏运行报错日志里输出一个 Cube(1) 或 New Material (1) 时你很难通过名字快速定位到具体资源也不容易和策划、美术口头沟通。资源名一旦通用于沟通场景它就是代码之外的另一份“文档”。1.3 命名规范的本质让资源名变成“第一行文档”命名规范本质上是在给资源建立一个稳定、唯一、可排序、可分组、可跨平台传递的标识。好的资源名应当满足几个条件唯一同一目录下没有重名不同语义不用同名。可读只看名字就能猜出业务含义不需要打开资源。可排序目录列表按字母排序后同类资源能自然聚在一起。可移植尽量使用 ASCII 字符避免空格和特殊符号减少构建工具链的兼容问题。稳定一旦定名并提交版本库就不要随手改来改去。很多人觉得命名是“小事”是规范强迫症。实际上一个命名规范清晰的项目新人接手时能很快找到资源命名混乱的项目哪怕代码写得再漂亮也会在资源层拖慢整体开发节奏。2. 环境与版本说明本文后续的脚本和示例基于 Unity 2020 LTS 至 Unity 6 期间的常见编辑器版本编写Editor API 方面主要使用了 AssetDatabase、Selection、EditorWindow 等长期稳定接口低版本到高版本之间基本兼容。如果你使用的是更老的 Unity 5.x 或 2017 系列接口大体一致但建议先在小工程里验证。示例项目结构以 Windows 环境为例macOS 和 Linux 下 Unity 编辑器本身的用法相同只是命令行入口名称不同。C# 脚本建议保存为 UTF-8 with BOM 编码尤其是脚本里包含中文注释时能避免不同编辑器之间出现中文乱码。需要说明的是本文给出的命名规则是“推荐实践”而不是 Unity 官方的强制约束。你可以根据团队情况调整前缀或后缀但核心原则——语义清晰、禁止默认命名、避免特殊字符——是通用的。3. Unity 资源命名核心规则3.1 大小写风格先统一 PascalCasePascalCase 指的是每个单词首字母大写、单词之间不加分隔符的写法例如 PlayerController、UILoginPanel、T_Player_Albedo 中的单词部分。Unity 里的 C# 脚本遵循 .NET 命名规范类名、方法名、公开字段通常使用 PascalCase私有字段习惯使用 camelCase 或带下划线前缀的 _camelCase常量使用 UPPER_SNAKE_CASE。这和 Java 的标识符规则类似C# 类名不能包含空格、不能以数字开头、不能是关键字。Unity 还有一个额外的硬性约束绑定到 GameObject 上的 MonoBehaviour 类名必须和脚本文件名保持一致。所以你新建一个脚本如果叫 NewBehaviourScript.cs类名也必须同步改为 NewBehaviourScript否则挂载组件时会报错。在资源命名上虽然贴图、材质、FBX 模型的文件名不受 C# 标识符约束但一旦资源名要作为代码里的字符串、Addressables 地址或 AssetBundle 名称使用就会间接受到同样规则的约束。因此全项目统一采用 PascalCase 是最不容易出错的方案。3.2 资源类型前缀与后缀约定纯大驼峰的命名适合类名和对象名但对于大量资源需要一种一眼就能分辨“这是贴图还是材质、属于哪个模块”的格式。比较通用的公式是类型前缀 业务模块 对象名 用途/序号例如 T_Player_Body_AlbedoT 表示贴图Player 表示角色模块Body 表示身体部位Albedo 表示用途。下面是一份可以参考的前缀表。资源类型推荐前缀/格式示例场景Lv_ 或 Scene_Lv01_Town、Lv02_Forest预制体PR_PR_Player、PR_Enemy_Knight材质M_ 或 Mat_M_Stone、M_Player_Body贴图T_ 或 Tex_T_Stone_Albedo、T_Player_Normal动画片段AC_AC_Walk、AC_Attack_01动画控制器ACtrl_ACtrl_Player音频BGM_ / SFX_ / VO_BGM_Menu、SFX_Hit、VO_Story_001UI 预制体UI_UI_LoginPanel、UI_Btn_Start可编程对象SO_SO_PlayerConfig、SO_ItemTable特效VFX_VFX_Explosion、VFX_HitSpark脚本类名 PascalCase文件名同名PlayerController.cs这里的重点是“全员共识”。前缀本身没有绝对标准但如果团队里有人用 M_ 表示材质、有人用 Mat_ 表示材质、还有人用 Material_那和没有规范没区别。3.3 目录结构也是命名的一部分资源规范不能只看单个文件名目录结构同样承担着“分组命名”的作用。建议把 Assets 目录按“资源类型”或“功能模块”拆成几大区域文件放对目录名字才能短而不乱。Assets/ ├── Scenes/ # 场景文件 ├── Art/ # 美术资源 │ ├── Characters/ # 角色 │ │ ├── Player/ │ │ └── Enemy/ │ ├── Environment/ # 场景物件 │ ├── UI/ # UI 相关 │ └── VFX/ # 特效 ├── Audio/ # 音频 │ ├── BGM/ │ ├── SFX/ │ └── VO/ ├── Scripts/ # 代码 │ ├── Player/ │ ├── UI/ │ └── Core/ ├── Settings/ # 全局配置、Input、Tag 等 └── Editor/ # 编辑器扩展脚本很多团队会把贴图和对应预制体放在同一个角色目录下这是允许的。只要目录分类稳定资源名里的“模块前缀”甚至可以缩短。3.4 明确禁止的命名模式下面的命名模式不是“不建议”而是“直接禁止”。首先是 Unity 默认命名。New Material、New Texture、New Sprite、New Behaviour Script、Cube、Sphere、Capsule、Plane以及它们带序号后的变体一律不允许存在于最终工程里。这些名字没有任何业务信息属于纯命名债务。其次是空格和中英文括号。文件名带空格后在命令行批处理、跨平台同步、代码字符串拼接时需要额外转义而括号通常是复制产生的默认后缀严重影响排序和可读性。统一用下划线替代空格。再次是数字开头。数字开头的文件在目录排序时不理想如果资源名被提取为 C# 代码里的字符串字面量还会带来额外的检查成本。需要序号时放在名字末尾例如 AC_Attack_01。还有一类是“最终版”“final2”“_bak”“副本”这类临时语义。这种名字说明资源状态不明确很容易出现一堆 final 最后都不知道哪个才是真的最终版。临时文件如果确定不再使用应直接删除或移入专门的 Trash 目录。4. Unity 资源命名规范实战这一节会用一个小型跑酷 Demo 为例演示如何从目录搭建开始到用编辑器工具批量清理命名。4.1 项目目录结构示例假设我们做一个简单的跑酷 Demo包含角色、障碍物、UI、音效和特效。清理后的目录结构如下Assets/ ├── Scenes/ │ └── Lv01_Runner.unity ├── Art/ │ ├── Characters/ │ │ └── Player/ │ │ ├── PR_Player.prefab │ │ ├── M_Player_Body.mat │ │ ├── T_Player_Body_Albedo.png │ │ ├── T_Player_Body_Normal.png │ │ ├── AC_Walk.anim │ │ └── AC_Dash.anim │ ├── Environment/ │ │ ├── PR_Obstacle_Stone.prefab │ │ ├── M_Stone.mat │ │ └── T_Stone_Albedo.png │ └── UI/ │ ├── UI_HudPanel.prefab │ └── T_UI_Btn_Start.png ├── Audio/ │ ├── BGM_Runner.mp3 │ ├── SFX_Jump.mp3 │ └── SFX_GetCoin.mp3 ├── Scripts/ │ ├── Player/ │ │ └── PlayerController.cs │ └── UI/ │ └── UIHudPanel.cs ├── Settings/ └── Editor/ └── NamingTools/ ├── AssetNamingChecker.cs └── AssetBatchRenamer.cs这个结构里每个资源的命名都包含类型前缀和语义信息即使不看内容也能大致猜到资源用途。4.2 场景对象命名示例资源文件清理完成后场景里的 GameObject 也应该遵循同样的规范。Hierarchy 窗口建议按“系统节点 模块分组 具体对象”组织GameRoot/ ├── Environment/ │ ├── Road_01 │ └── Tree_Birch_01 ├── Characters/ │ ├── Player │ │ ├── Body │ │ ├── Weapon_Sword │ │ └── VFX_DashTrail │ └── Enemy_Knight_01 ├── UI/ │ ├── UI_HudPanel │ ├── UI_Btn_Start │ └── UI_Txt_CoinCount └── System/ ├── GameManager └── AudioManager场景对象的命名有两点好处一是运行时日志里出现对象名时可以直接定位模块二是脚本里 Find 或 GetComponent 时名字稳定可预期。4.3 用 Editor 脚本自动检查命名人工检查几千个资源不现实更可行的是把命名规则写进 Editor 工具。下面是一个资源命名检查器的完整代码放在 Assets/Editor 目录下即可。文件路径Assets/Editor/NamingTools/AssetNamingChecker.csusing System.IO; using System.Text.RegularExpressions; using UnityEditor; using UnityEngine; public static class AssetNamingChecker { [MenuItem(Tools/命名检查/检查整个项目)] public static void CheckProjectAssets() { int badCount 0; string[] guids AssetDatabase.FindAssets(, new[] { Assets }); foreach (string guid in guids) { string assetPath AssetDatabase.GUIDToAssetPath(guid); bool isFolder AssetDatabase.IsValidFolder(assetPath); // 文件夹用自身名字文件去掉扩展名再检查 string nameForCheck isFolder ? Path.GetFileName(assetPath) : Path.GetFileNameWithoutExtension(assetPath); // 规则1包含空格 if (Regex.IsMatch(nameForCheck, \s)) { Debug.LogWarning($[包含空格] {assetPath}); badCount; } // 规则2包含中英文括号通常是复制产生的默认命名 if (Regex.IsMatch(nameForCheck, [()])) { Debug.LogWarning($[包含括号] {assetPath}); badCount; } // 规则3以数字开头 if (Regex.IsMatch(nameForCheck, ^\d)) { Debug.LogWarning($[数字开头] {assetPath}); badCount; } // 规则4命中 Unity 默认命名 if (Regex.IsMatch(nameForCheck, ^(NewBehaviourScript|New|Cube|Sphere|Capsule|Plane)([ (_]|$))) { Debug.LogWarning($[默认命名] {assetPath}); badCount; } } if (badCount 0) { Debug.Log(资源命名检查通过未发现明显问题。); } else { Debug.Log($资源命名检查完成发现 {badCount} 个问题请逐个处理。); } } }这段代码里有几个值得解释的点。AssetDatabase.FindAssets 是 Unity 编辑器下最常用的资源搜索接口第一个参数是搜索过滤条件空字符串表示匹配所有资源返回的是资源的 GUID 数组而不是路径。GUID 是 Unity 内部给每个资源分配的唯一标识和文件名解耦这也是 Unity 能在编辑器里放心重命名文件而不破坏引用的根本原因。AssetDatabase.IsValidFolder 用来判断一个路径是否是文件夹。因为 FindAssets 的空过滤条件会把目录也返回进来检查时先区分文件夹和文件文件夹用自身名字检查文件则去掉扩展名检查否则 .png、.mat 这类扩展名会影响正则匹配。四个检查规则分别对应前面提到的禁止项空格、括号、数字开头、Unity 默认命名。Debug.LogWarning 会把问题直接输出到 Console双击日志还能自动定位到对应资源。4.4 用 Editor 窗口批量重命名检查出来一堆问题手动一个个改也很累。再看一个批量重命名工具的代码它会把选中资源的空格和括号统一替换为下划线。文件路径Assets/Editor/NamingTools/AssetBatchRenamer.csusing System.IO; using System.Text.RegularExpressions; using UnityEditor; using UnityEngine; public class AssetBatchRenamer : EditorWindow { private string pattern [\s()]; private string replacement _; [MenuItem(Tools/命名工具/批量修正命名)] public static void OpenWindow() { AssetBatchRenamer window GetWindowAssetBatchRenamer(批量修正命名); window.minSize new Vector2(420, 180); } private void OnGUI() { EditorGUILayout.HelpBox( 选中 Project 窗口中的资源或文件夹点击按钮即可把名称里的空格、括号替换为下划线。, MessageType.Info ); pattern EditorGUILayout.TextField(匹配正则, pattern); replacement EditorGUILayout.TextField(替换为, replacement); if (GUILayout.Button(扫描并重命名选中资源)) { ApplyRename(); } } private void ApplyRename() { if (Selection.objects null || Selection.objects.Length 0) { Debug.LogWarning(请先在 Project 窗口选中需要重命名的资源。); return; } int count 0; foreach (Object selected in Selection.objects) { string assetPath AssetDatabase.GetAssetPath(selected); if (string.IsNullOrEmpty(assetPath)) { continue; } // 对于场景里的 GameObjectGetAssetPath 通常返回空因此这个工具只处理 Project 资源 string fileName Path.GetFileName(assetPath); string newFileName Regex.Replace(fileName, pattern, replacement); if (newFileName fileName) { continue; } // RenameAsset 只需要传资源名不要带扩展名 string newName Path.GetFileNameWithoutExtension(newFileName); string error AssetDatabase.RenameAsset(assetPath, newName); if (string.IsNullOrEmpty(error)) { count; string directory assetPath.Substring(0, assetPath.LastIndexOf(/) 1); Debug.Log($已重命名{assetPath} - {directory}{newFileName}); } else { Debug.LogError($重命名失败{assetPath}原因{error}); } } AssetDatabase.SaveAssets(); AssetDatabase.Refresh(); Debug.Log($处理完成共重命名 {count} 个资源。); } }这里最关键的是 AssetDatabase.RenameAsset。它接受两个参数旧资源的完整路径以及新的资源名不带扩展名。函数返回空字符串表示成功返回非空字符串则表示错误信息。因为 Unity 的资源引用基于 meta 文件里的 GUID而不是文件名所以在编辑器内部重命名资源场景和预制体里的引用不会断裂。这也是为什么我一直强调改名要在 Unity 编辑器里做不要直接去 Windows 资源管理器里改文件名后者会丢失 meta 文件破坏整个工程的引用关系。批量修改完成后调用 AssetDatabase.SaveAssets 保存资源再调用 AssetDatabase.Refresh 刷新编辑器确保文件系统状态和 Unity 内部状态一致。4.5 运行与验证两个工具放置成功后Unity 顶部菜单栏会出现 Tools 菜单。点击 Tools 命名检查 检查整个项目Console 窗口会输出所有违规资源列表。假设我们的工程没有清理输出类似[包含空格] Assets/Art/New Material.mat [括号] Assets/Prefabs/Cube (1).prefab [默认命名] Assets/Art/Cube.prefab [数字开头] Assets/Art/3D_Street_Model.fbx 资源命名检查完成发现 4 个问题请逐个处理。然后再打开 Tools 命名工具 批量修正命名选中需要处理的文件点击按钮即可批量替换。修正后再跑一次检查Console 会提示“资源命名检查通过”。Editor 脚本还可以接入命令行方便在 CI 上定时检查。Windows 下 Unity 命令行大致如下Unity -batchmode -quit -projectPath D:\MyProject -executeMethod AssetNamingChecker.CheckProjectAssets -logFile -注意这里的 Unity 不是环境变量里的命令需要替换为你本机 Unity 编辑器的实际安装路径比如 C:\Program Files\Unity\Hub\Editor\2022.3.0f1\Editor\Unity.exe。不同版本安装路径不同实际使用时按自己环境调整。5. 常见命名问题与排查思路下面整理了一张 Unity 资源命名相关的问题排查表覆盖了最常见的几类情况。问题现象常见原因解决思路场景里出现 Cube(1)、Sphere(2)多次拖入同一模型或复制对象Unity 自动追加序号建立“创建后立刻改名”的肌肉记忆或用批量重命名工具清理一次资源改名后代码引用失效手动在系统资源管理器里改了文件名meta 文件丢失必须在 Unity 内用 AssetDatabase.RenameAsset 或 Project 窗口重命名脚本文件重命名后挂载组件报错类名和文件名不一致同时修改类名和文件名推荐用 IDE 的重命名重构功能用 Resources.Load 加载资源失败资源路径里含空格或特殊字符路径字符串不匹配清理资源名代码里严格使用相对路径不写扩展名中文资源名在命令行构建时报错构建工具链编码不兼容或系统区域设置不同团队资源统一用英文 PascalCase中文仅用于资源描述字段资源名只差大小写Linux 构建异常Windows/macOS 文件系统不区分大小写Linux 区分禁止出现仅有大小写差异的同名资源除了表格里这些还有一个容易被忽略的问题场景里的 GameObject 和 Project 里的 Prefab 名字不一致。预制体 AssetDatabase.RenameAsset 改名后场景里实例化的对象名不会自动同步需要在场景里重新命名实例或者通过编辑器工具批量同步。这类问题虽然不是“报错”但很容易造成混淆。另外要提醒的是任何批量重命名操作前最好先执行一次 Assets Save Project并且保证当前改动已经提交版本控制。虽然 GUID 引用不会因为重命名断裂但万一操作中断有版本控制兜底会更安全。6. 团队协作中的命名规范落地6.1 先把规范写成文档命名规范最大的难点不是“定规则”而是“让全组用同一套规则”。建议在工程根目录放一份 NamingRules.md写清楚以下内容资源类型前缀表每个前缀给 1-2 个示例。目录分类规则什么资源放哪个目录。禁止项清单比如默认命名、空格、括号、数字开头。改名流程规定只能通过 Unity 编辑器重命名。审查 checklist提交代码和资源的 MR/PR 时逐项对照。文档要精简。如果写了几十页没人看还不如一份一页纸的前缀速查表。6.2 让检查工具变成团队默认工具前面写的 AssetNamingChecker 放到公共工程的 Assets/Editor 目录后所有团队成员都会看到 Tools 菜单每次合并代码后跑一遍检查命名问题就能及时暴露。更严格的团队可以把检查命令接入 CI在打包前增加一个命名检查环节检查不通过则构建失败从流程上堵住命名违规。这里要控制检查规则的严格程度。比如目录里如果有第三方插件插件的资源命名风格可能完全不同全项目扫描会把大量第三方资源也列为违规。更合理的做法是只检查自己的业务资源目录或者在脚本里加一个忽略目录列表。6.3 版本控制与 meta 文件注意点Unity 工程默认会为每个资源生成一个 .meta 文件里面保存了资源的 GUID、导入设置和依赖信息。这个文件必须和资源文件一起提交到版本控制否则换个环境后 GUID 重新生成所有引用都会失效。在命名规范落地过程中要注意三点不要在版本控制的导出包里直接改名先在本地编辑器里改名再提交。批量重命名后立即检查版本控制状态确认 .meta 文件也同步变更。不要同时进行大规模资源重命名和代码重构两件事分开做出问题容易定位。如果团队使用 Git建议在 .gitattributes 中为 .meta 文件配置合并策略避免多人同时改动同名资源时产生冲突。具体配置因团队工作流而异这里只提醒原则meta 文件的正确性比资源文件本身更脆弱。6.4 中文命名的取舍很多国内团队习惯用中文给资源命名例如“主角材质”“登录按钮”。Unity 编辑器本身对中文文件名支持良好小团队前期使用完全没问题。但中文命名在下面这些场景里容易出问题命令行构建输出和日志编码、外部美术工具链导入导出、不同语言系统的自动化脚本、部分第三方插件和资源包管理流程。我的建议是如果团队成员全在相近环境工作、工具链简单中文命名可以接受但只要有跨部门协作、外发或自动化构建就统一改为英文 PascalCase中文含义可以记录在规范文档的注释里。资源名是跨平台、跨工具链的中间产物越接近“纯 ASCII 字符串”后期越省心。7. 总结与后续学习路线到这里Unity 资源命名的基本规则、检查工具和排错思路就完整过了一遍。其实核心要点可以浓缩成三句话资源名要能表达“类型 模块 用途”而不是依赖 Unity 的默认命名。目录、文件名、场景对象名要使用同一套风格大小写和分隔符保持统一。用 Editor 脚本把命名规则固化下来人工检查永远追不上几千个资源的规模。如果你正在新开项目建议从第一天就按这套规范执行成本最低如果你接手的是一个命名堆成山的历史项目先跑一遍 AssetNamingChecker 看看违规数量再分批清理不要试图一个下午全部改完。每清理完一个模块就提交一次版本控制风险更小。下一步可以继续学习三个方向Addressables 资源管理系统中如何利用命名规划分组地址AssetBundle 构建时如何让包名、变体名和资源路径互相呼应以及 Unity 资源依赖分析工具用来在重命名后检查哪些资源仍然被引用。这些内容和命名规范结合起来才能真正解决大型项目的资源管理问题。如果你项目里的 New Material 已经堆成山不妨先跑一遍检查工具看看总数然后在评论区分享一下你见过的“最离谱资源名”我们看看谁的工程命名债务最重。