1. 核心能力速览在 Unity 项目里命名规范看起来是最不起眼的事但恰恰是它决定了项目能走多远。能力项说明适用对象Unity 开发者、游戏美术、技术美术、独立开发者、项目负责人核心功能制定并落地 Unity 资源命名规范减少重复资源、脚本引用失效、Git 冲突和协作混乱覆盖范围场景物体、Prefab、材质球、纹理、Shader、脚本、Animator Controller、音频、UI、文件夹结构适用引擎版本Unity 2018 LTS 至 Unity 6 通用不同版本 UI 路径略有差异难点不是“不知道规则”而是旧项目已经积攒了大量 Cube(1) 这种历史包袱落地方式命名规范 Editor 脚本批量检查 文件夹分区 Git 提交前的资源名审查适合读者正在做团队协作、接手老项目、打算长期维护 Unity 工程的人这篇文章不聊渲染不聊玩法只聊一件事Unity 资源的命名到底该怎么定才能让项目在三个月后还能被自己和队友看懂。2. 为什么 Cube(1)、New Material 这种命名会拖垮项目很多刚入门的 Unity 开发者在操作编辑器的时候习惯直接复制一个 Cube于是 Hierarchy 面板里出现Cube(1)、Cube(2)然后不小心又复制了一个材质球默认就叫New Material。顺手在场景里摆了几棵树的模型Unity 自动给它们起名叫Tree、Tree(1)如果某个 Prefab 被反复拖进场景命名甚至会变成Tree(1)(Clone)。这种命名方式在单机小 Demo 里完全没问题但一旦进入以下场景就会立刻暴露问题。2.1 资源无法定位场景里的Cube(1)到底对应项目里的哪个 Prefab材质球叫New Material它的 Shader 是什么贴图是哪个当美术给你一个模型文件你把它拖进场景如果不重新命名整个场景就变成了一堆默认名。过一周再打开工程你会对着Cube(1)、Cube(2)、Sphere(3)发呆完全不知道哪个是地面、哪个是角色、哪个是墙壁。2.2 脚本引用和查找效率低Unity 的脚本搜索、资源查找、批量替换都依赖文件名。如果所有材质都叫New Material当你想批量修改某个材质的金属度时你就只能一个材质一个材质地点开查看。同样的道理也适用于 Animator ControllerNew Animator Controller挂在角色上你完全看不出这个控制器是控制走路还是攻击。2.3 Git 合并时命名的“隐形炸弹”Unity 里每个资源都对应一个.meta文件这个文件里记录着 GUID。资源的文件名是否稳定直接影响版本管理。如果你把Cube改名为Ground_CubeUnity 会自动更新场景中对应引用的 GUID。但如果两个人同时修改同一个场景一个人把物体改名为Ground_Cube另一个人也在这个场景里加入了新的同名物体Git 就会在.unity场景文件里产生大量冲突。到了解决冲突的时候你看着一堆Cube(m_CorrespondingSourceObject)根本不知道谁是谁。实际上很多从 Unity 2018、Unity 2019 时代一路升级上来的老项目资源命名问题会比新项目更严重因为早期的 Unity 教程普遍默认直接创建 Cube 演示新手跟着教程做了一遍就把默认命名带到了自己的项目里。2.4 热词背后暴露的真实痛点从近期的 Unity 开发热词可以看到很多人在搜“unity 图文混排”“unity 微信小游戏打包”“unity 模型遮挡剔除插件”“unity 数字孪生”。这说明 Unity 开发者的业务范围正在从纯游戏扩展到数字孪生、互动媒体、多人协作、复杂 UI 等场景。项目越复杂资产管理就越重要。一个数字孪生项目可能有几百栋建筑模型、上千个材质、几十个 Shader如果命名混乱整个工程会直接变成一个黑盒。3. 先建立一套最小可行的命名规范我们不需要一步到位制定覆盖所有情况的复杂规范先把最核心的部分定下来。我建议的规则是3.1 场景物体命名对象类型 用途 序号场景物体名建议用“语义 类型”的格式让任何人看见名字就知道这个物体是什么。Ground_Quad Player_Capsule Enemy_01 Door_Left Wall_Trim Interior_Table_01这里有个细节Unity 默认创建的对象名是Cube、Sphere、Capsule、Plane这些是“体素名”不是“业务名”。我们应该用业务名替换它们。比如一个表示地面的 Cube正确命名是Ground_Quad而不是Cube哪怕它的实际 Mesh 依然是 Cube但名字会说明它在场景里的用途。3.2 材质球命名资源前缀 物体 颜色/用途材质球是最容易出现New Material的地方。建议格式Mat_Floor_Wood Mat_Wall_White Mat_Char_Skin Mat_Env_Sky_02 Mat_Tree_01注意Mat_前缀。在 Unity 的 Project 搜索框里输入Mat_就能过滤出所有材质配合t:Material使用效果更佳。这是我喜欢用前缀的原因它可以形成一种命名空间。3.3 纹理贴图命名物体 贴图类型贴图命名格式Char_Hero_Diffuse Char_Hero_Normal Char_Hero_Mask Floor_Tile_Albedo Tree_01_Bark_Basecolor关于 Diffuse、Albedo、BaseColor 这一组词关键是团队内部统一。不要一个人用_Diffuse另一个人用_BaseColor第三个人用_Albedo否则搜索时会漏资源。如果项目是 PBR 流程建议统一使用_BaseColor、_Normal、_Mask、_Metallic、_Roughness这类带明确物理含义的后缀。3.4 脚本命名PascalCase 语义完整脚本的命名会影响组件、菜单项、序列化字段和类名一定要按 PascalCase 来PlayerController.cs EnemySpawner.cs UIManager.cs InventorySystem.cs这里有个容易踩的坑脚本文件名必须和类名一致否则 Unity 无法挂载组件。所以改脚本文件名时要同步改类名。3.5 UI 命名UI 类型 业务模块UI 在项目里是最容易产生同名的地方因为复制 Panel 特别方便。推荐格式Btn_Start Txt_PlayerName Img_Avatar Panel_Setting ScrollView_ItemList SLider_Volume3.6 文件夹命名小写下划线 按功能分类文件夹名建议全部小写 下划线这和 Unity 默认的Assets、Scenes、Prefabs大小写不完全一致。它可以避免不同操作系统的文件名大小写不一致问题。assets/ ├── scenes/ ├── prefabs/ ├── materials/ ├── textures/ ├── models/ ├── scripts/ ├── shaders/ ├── audio/ ├── animation/ ├── ui/ └── art_resources/如果项目比较小也可以直接以“资源类型”做顶层分区场景归Scenes模型归Models材质归Materials。但如果项目已经做到多人协作建议按“资源类型 → 功能模块”两层组织Assets/ ├── Scenes/ ├── Prefabs/ │ ├── Player/ │ ├── Enemy/ │ └── Props/ ├── Materials/ │ ├── Character/ │ ├── Environment/ │ └── UI/ ├── Textures/ │ ├── Characters/ │ ├── Environments/ │ └── UI/4. 从路程到落地一键排查场景里的坏命名规范的制定只需要几分钟真正难的是老资源的清理。手动一个个改是可行但极其枯燥的而且很容易漏掉。更稳妥的方式是用一件事把命名问题变成一个可检测的工程问题。我们可以写一个小的 Editor 脚本自动扫描当前场景中的物体找出不符合规范的命名并批量统一修改。4.1 打开 Editor 脚本目录在 Unity 中新建Scripts/Editor/ResourceNameChecker.cs。注意目录必须带Editor否则脚本会被打进游戏包。4.2 编写场景物体命名检查器using UnityEngine; using UnityEditor; using System.Collections.Generic; public class ResourceNameChecker : EditorWindow { private static string invalidPrefix Cube; private static string invalidName New Material; [MenuItem(Tools/资源命名检查/扫描当前场景)] public static void ScanCurrentScene() { GameObject[] allObjects GameObject.FindObjectsOfTypeGameObject(); ListGameObject invalidObjects new ListGameObject(); foreach (GameObject obj in allObjects) { if (obj.name.Contains(invalidPrefix) || obj.name.Contains((Clone)) || obj.name.Contains(New Material)) { invalidObjects.Add(obj); } } Debug.Log($扫描完成发现 {invalidObjects.Count} 个不符合命名规范的物体); foreach (GameObject obj in invalidObjects) { Debug.Log($问题物体{obj.name}路径{GetPath(obj.transform)}); } } private static string GetPath(Transform current) { if (current.parent null) return current.name; return GetPath(current.parent) / current.name; } [MenuItem(Tools/资源命名检查/批量重命名场景物体)] public static void RenameInvalidObjects() { GameObject[] allObjects GameObject.FindObjectsOfTypeGameObject(); int count 0; foreach (GameObject obj in allObjects) { if (obj.name.StartsWith(Cube() || obj.name.StartsWith(Sphere()) { Undo.RecordObject(obj, Rename invalid object); string newName $Object_{obj.transform.position.x:F0}_{obj.transform.position.y:F0}_{obj.transform.position.z:F0}; obj.name newName; count; } } AssetDatabase.SaveAssets(); Debug.Log($批量重命名完成共修改 {count} 个物体); } }4.3 执行扫描在 Unity 菜单栏找到Tools - 资源命名检查 - 扫描当前场景运行后在 Console 面板观察结果。你会发现Cube(1)、Cube(2)、New Material这类名字被全部列出来并附带了完整层级路径。这个脚本的价值不在于名字本身而在于把“检查”变成了一种可以反复执行、附带了定位路径、可以统计数量的自动化操作。它不需要人工审查只要跑一遍就能知道当前场景还有多少隐患。4.4 批量重命名要注意什么批量重命名脚本里我加了Undo.RecordObject这是关键。没有它一旦误操作你就无法在编辑器里回退。其次重命名是一个不可逆过程它会影响*.unity场景文件、*.prefab文件和*.meta文件。执行前必须提交一次 Git 快照或手动备份。5. 材质和贴图层面的命名治理场景物体虽然是重灾区但材质和贴图的命名问题更隐蔽。材质资源在 Project 窗口中占的比重很大一个大型项目动辄几千个材质球如果没有前缀规范查找时会非常痛苦。5.1 使用 Search Filter 过滤资源类型在 Unity Project 窗口的搜索框中可以直接输入t:Material Mat_这会列出所有以Mat_开头的材质球。t:Texture2D _Normal这会列出所有文件名包含_Normal的贴图。t:Prefab Btn_这会列出所有以Btn_开头的 UI Prefab。这套搜索方式非常实用它不依赖任何插件是 Unity 编辑器自带的能力。命名规范和搜索习惯结合在一起效率提升是肉眼可见的。5.2 从导入模型的最初环节定好命名当你从 ArtStation、Sketchfab 或者美术同事手里拿到一个 FBX 模型时首先要做的事情是检查压缩包里的贴图名。如果贴图叫texture_001、texture_002进 Unity 后改名的成本极高因为材质球已经通过导入设置自动绑定到了这些贴图。强烈建议在 Unity 导入前完成贴图重命名或者在导入后使用写一个小的资源处理工具在OnPostprocessAllAssets阶段自动整理。public class AssetImportNaming : AssetPostprocessor { private void OnPreprocessModel() { ModelImporter importer assetImporter as ModelImporter; if (importer ! null) { importer.importMaterials true; importer.materialName ModelImporterMaterialName.UsingModelMaterialName; } } private void OnPreprocessTexture() { // 这里只是打印贴图导入路径方便后续检查 // 实际项目可以在这里按规则自动重命名贴图 } }这个思路是在资源导入的那一刻就把命名问题解决而不是等资源进入工程后再事后处理。6. Git 协作中的命名坑位与 Git 配置Unity 项目在 Git 协作中的典型问题是场景文件合并困难和.meta文件冲突。资源命名对这两件事有直接影响。6.1 场景文件合并困难一个 Unity 场景文件本质上是 YAML 文本里面记录着 GameObject 的 name、组件、引用关系和坐标。当你把物体从Cube(1)改成Ground_Quad后m_Name字段会发生变化但同一个物体的m_LocalIdentifier不会变。如果队友基于修改前的状态也做了场景修改Git 合并时就会出现冲突。建议在团队协作中启动 Unity 的“Text Serialization”文本序列化模式。在 Project Settings - Editor - Asset Serialization 中选择Force Text。这样场景、Prefab 和资源都以文本形式存档Git 对比会更友好。6.2 大写入文件名的 .meta 问题Unity 的.meta文件默认与资源同名。当你用资源管理器把Cube.meta改成Ground_Cube.meta要注意你在 Unity 编辑器里改名Unity 会自动更新所有引用但如果你在操作系统资源管理器或者 Git 里直接更名就会导致.meta与资源不匹配Unity 会重新生成.meta从而丢失原来的 GUID所有场景中对该资源的引用会全部丢失。所以稳妥的改名流程是在 Unity 编辑器内部重命名资源不要在外部改名。6.3 Git LFS 与资源混淆如果项目里的贴图、模型、音频使用 Git LFS 管理大文件会被替换成指针文件。资源命名规范配合git lfs migrate可以避免仓库膨胀但更关键的是名字一旦包含(1)这种无意义后缀Git 会比较难判断是否真的需要追踪该文件。建议在团队项目规范中明确任何文件名不允许出现空格、括号、特殊符号。关于 Git 换行符的问题Unity 项目在 Windows 和 macOS 之间协作时经常遇到LF和CRLF的告警。解决方案是在项目根目录添加.gitattributes文件统一强制使用LF。* textauto *.cs text eollf *.unity text eollf *.prefab text eollf *.asset text eollf *.mat text eollf *.shader text eollf *.png binary *.jpg binary *.fbx binary *.mp4 binary *.wav binary6.4 利用 Git 提交前检查拦截坏命名既然团队用 Git就可以在提交前做一次拦截。在团队的 CI 或者本地提交钩子里写一段简单的脚本扫描本次提交的目录中是否存在Cube(1)、New Material这类命名。#!/bin/bash # 提交前检查 Unity 资源命名 # 需要替换为你们的项目目录 PROJECT_DIR./Assets INVALID_NAMES$(find $PROJECT_DIR -name *(1) -o -name New Material -o -name * .*) if [ -n $INVALID_NAMES ]; then echo 提交失败项目中存在不符合命名规范的资源文件 echo $INVALID_NAMES exit 1 fi exit 0这个脚本在 Windows 上需要 Git Bash 环境运行在 macOS 和 Linux 上直接使用。它的实现思路很简单在提交前扫一遍文件名发现括号和默认名就阻塞提交。7. 常见命名问题排查与处理清单现象原因排查方式解决方案场景里出现Cube(1)直接复制默认物体Project 搜索t:GameObject Cube批量重命名脚本替换材质球全部叫New Material创建后未改名搜索t:Material New按Mat_用途规范重命名脚本挂不上组件脚本类名与文件名不一致打开脚本对比类名类名改为与文件名一致Git 产生大量场景冲突多人同时修改场景文件Git diff 查看.unity文件拆分子场景统一角色分工资源改名后引用丢失在操作系统外部直接改文件名检查.meta文件是否更新在 Unity 编辑器内重命名大量LF/CRLF告警Windows 和 macOS 混合协作git config core.autocrlf添加.gitattributes强制eollfPrefab 拖进场景出现(Clone)运行时实例化脚本中用obj.name 固定名动态实例化后重新命名7.1 比较麻烦的是 Prefab 的 (Clone)运行时通过Instantiate生成的物体Unity 会自动在名字后面追加(Clone)。这在运行时是正常的但如果这个物体被序列化到场景里或者你把它当 Prefab 保存下来名字就会一直带着(Clone)。解决方式是在实例化后手动改名GameObject go Instantiate(enemyPrefab); go.name Enemy_01;团队规范里也应该明确运行时实例化后的物体必须重新设置逻辑名不允许保留(Clone)。7.2 老项目如何逐步清理老项目不一定非要一次性把所有命名全部改完。改动越大出现问题的概率越高。更稳妥的做法是分阶段清理第一阶段只清理Assets/Scenes下面当前正在开发的场景保证场景物体命名清晰。第二阶段清理 Prefab 本身因为场景中对 Prefab 实例的重命名并不会影响 Prefab 源文件。第三阶段清理材质、贴图和 Shader 的命名这是一个长期过程没关系每天顺手改几个。第四阶段引入 Editor 脚本把命名检查变成日常开发的一部分。如果你正在处理的是一个巨大的老项目里面包含了大量从 Unity 2018 时代带入的资源那么请记住一个原则不要在一个未提交 Git 备份的项目上做大规模重命名。先把 Git 仓库拉干净、提交一次基线然后重命名再提交一次。这样如果出问题随时可以回退。8. 从命名到规范一个可持续落地的工程方案命名规范要落地不只是一份文档还应该被编码到工具和流程里。我把这套可持续的方案整理成四步。8.1 把命名规范写进项目 README在项目根目录创建README.md用一段最核心的规范说明资源命名约定并在Assets目录下放置_AssetNaming.md文档。团队成员可以随时查阅新人入职后也能快速对齐。建议的文档结构# Unity 项目资源命名规范 ## 场景物体 - 格式类型_用途_序号 - 示例Ground_Quad_01、Door_Left_01 ## 材质 - 格式Mat_所属_颜色/用途 - 示例Mat_Wall_White、Mat_Character_Hero ## 贴图 - 格式所属_贴图类型 - 示例Char_Hero_Diffuse、Char_Hero_Normal ## 脚本 - 命名PascalCase - 示例PlayerHealth.cs、UIManager.cs ## 禁止事项 - 禁止 Cube(1)、New Material、空格、特殊字符 - 禁止在 Unity 外部直接修改文件名8.2 用 Editor 窗口把检查工具化前面的ResourceNameChecker只是初版实际落地时可以扩展成完整的 Editor 检查窗口[MenuItem(Tools/资源命名规范检查)] public static void OpenAssetNamingWindow() { // 这里可以扩展为一个 EditorWindow // 扫描场景、材质、贴图、Prefab 和文件夹 // 输出不符合规范的项目清单 }这个检查工具要包含四个核心能力扫描当前场景中不符合规则的物体名。扫描 Project 中所有材质球名和贴图文件名。检查文件夹结构是否合理。把检查报告输出为文本文件可以直接贴进提交信息里。8.3 把规范绑定到 Git 流程团队如果使用 Git推荐在服务端配置 pre-receive 钩子或者本地 pre-commit 钩子。每次提交前自动检查资源目录中的新增文件命名。在实际项目中这个方法能拦截大部分低级错误。哪怕做不到自动拦截至少要在 MR/MR 的模板中给出命名规范的检查字段让每个提交人都需要确认自己提交的资源命名符合规范。8.4 关于 Unity 的 50 系显卡、数字孪生与 AI 协同最近 Unity 相关热词中出现了如何将figma里面的ui导入到unity中、unity微信小游戏打包、unity数字孪生、cursor如何读取unity项目等问题。很多这代开发者不仅需要掌握 Unity 编辑器操作还在尝试用 AI 工具辅助编代码、生成 UI、处理资源。在这种情况下命名规范的作用会更加明显AI 工具读取项目时会根据资源名和文件名推断项目结构。如果项目里全是Cube(1)、New MaterialAI 很难给出准确的修改建议。用 Cursor 等 AI 工具辅助编写 Unity 脚本时如果你已经遵循PlayerController、EnemySpawner这类 PascalCase 命名AI 生成的代码在引用类名时会更加准确。从 Figma 导入 UI 时如果图层命名是Frame 1、Frame 2导入 Unity 后大概率会变成Frame 1(1)、Frame 2(1)之类的名字。这就要求在设计阶段、导入阶段、Unity 处理阶段都统一规范。9. 最终建议命名的问题看起来小但它会持续渗透到资源定位、脚本引用、Git 合并、AI 工具协同、团队沟通和项目维护的每一个环节。本文没有讨论任何新的渲染技术和编辑器技巧就是帮 Unity 项目把地基打正。如果你的项目目前已经存在大量Cube(1)、New Material这类命名不用焦虑。建议先跑一遍我给的ResourceNameChecker打印出问题清单评估影响范围然后先处理自己正在开发的场景最后再逐步向 Assets 全目录推广。当然命名规范没有绝对的统一答案团队内部只要能达成共识并执行下去比强行套用任何外部的“最佳实践”都重要。最怕的是文档写了一大堆代码提交时又复制出了一个Cube(3)。与其这样不如先把检查工具跑起来并让 Git 在提交时帮你拦下一部分明显不合理的命名。规范的价值最终体现在日常开发的细节里一个叫Door_Left_01的物体比一个叫Cube(1)的物体至少让三个月后的自己少花十分钟的查找时间。