Unity资源规范

本文最后更新于 2026年2月23日 晚上

Unity资源规范

命名规范

一个资源该如何命名？

  • 优先使用英文命名、其次中文，不建议使用汉语拼音。
  • 如果定好了命名语言，尽可能保证同一文件夹的文件都统一，别混用。
1
2
3
ShiZi //不建议（必须人工解读，但没有声调和上下文，难以正确解读。石子、狮子、柿子？）
Persimmon //正确（放入翻译软件中即可得为：柿子）
柿子 //正确（一眼看懂，但部分底层软件存在兼容问题，但不会影响功能使用）
  • 如果基于英语或拼音，那应采用“帕斯卡命名法”（每个单词首字母大写）。
  • 确保利用驼峰分割名称后，可从翻译软件中得到对应中文。
1
2
3
//正确（大写字母能起到分隔符的作用，添加空格后可以从翻译软件反向查到对应中文）
TourGuide
TourGuideHat
  • 不要使用纯简单的字母、数字、预设名称等无意义命名，命名必须能解释自身内容。
1
2
3
4
5
6
//错误示范（看了让人不知道相关资源是干啥的）
a
1
白1
微信图片_20251224112419_4_2
Circle_004 1
  • 当文件夹用于分类用途时，应将其采用英语且复数形式命名，并优先使用Unity的预设名称（参考存放规范）。
1
2
//正确（这不仅按规范来了，而且这是Unity标准的存放纹理的文件夹，会影响Unity自动链接纹理的方式）
Textures

存放规范

多个资源该如何存放？

设计理念

  • 存放的目的：

    基于作用域控制暴露的文件信息。

    存放的基本方法参考了程序中的作用域思想，一个物体的作用域是指“该物体可以被哪些其他物体使用，又或者说可以使用哪些其他物体”。资源存放以文件夹为容器，每个资源的作用域就受限于其所存储的文件夹及其同目录的其他文件夹。这样可以实现封装的思想（不需要关注子文件夹的内容，子文件夹由父文件夹的资源进行调度）以此文件夹才有了收纳作用。

  • 存放的方法：

    在基本结构下，先按模块放，再按类型放。

    1. 兼容特殊文件夹，以Unity的官方文件夹设计为原型。
    2. 实现模块化，便于快速以功能为单位进行文件管理。
    3. 同类型放一起，以便对资源进行各种批量预处理操作。

项目基本结构

这是对原则第一点的实现，定制了对Assets文件夹的标准骨架。其中前缀有加减号表示是文件夹，加减代表其是否展开；此外所有特殊文件夹都使用英文名称，示例的自定义文件夹则采用中文命名。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
+ Assets
  + Artworks：存放美术资源等游戏原始素材。
    - Audios：音频文件
    - Videos：视频文件
    - UI：用户界面用到的图片
    - Effects：特效相关
    - Models：模型相关
  - Editor：存放编辑器扩展，会影响编译范围。（官方）
  - Plugins：存放第三方插件，会影响编译顺序。（官方）
  - Resources：Resources功能所用，会影响资源剥离。（官方）
  - Samples：存放包示例。（官方）
  - Scenes：存放打包场景。（官方）
  - StreamingAssets：需应用携带但不希望被打包的资源。（官方）
  - Settings：存放全局项目设置，例如渲染管线、默认字体、默认导入设置等。
  - Sources：存放实现的功能模块，包括源代码、相关Unity资源、做好的预制体等。

  • Artworks 和 Sources：

    在接入 git 的环境下，美术师主要在 Artworks 文件夹工作，程序员主要在 Sources 文件夹工作，否则所有文件夹都由程序员管理。多人协作时，程序员有义务监督规范项目结构，以便实现功能需求、提高开发效率等。

  • Effects 和 Models：

    Effects 是特效师做好的成品，Models 是建模师提供的原始素材。

    这两个文件夹都会存储一些模型材质纹理资源，但两者的目的不同，Effects 由特效师管理，程序员理论上只管使用（通常程序员不会做特效）。Models 则是建模师仅提供资源，由程序员负责管理组装，该文件的内容，程序员能处理也需要处理，因为它通常不能像特效那样拿来就能用。

  • Assets：

    该文件夹是Unity文件系统中的根目录，需要注意的是，除了上述提到的结构，以及其他自动生成、插件依赖、无法移动的文件外，不允许在其中放入其他文件或文件夹。因为他本身就已经够臃肿了，而且直接放在根目录没有任何收纳作用，自定义文件夹请放入自己的模块文件夹中。

  • Editor：

    该文件夹是Unity的特殊文件夹，放在其中的脚本可以确保只在编辑器内使用，打包时会自动剥离，该文件夹放在任何子文件夹下都是可以的，故建议还是优先模块化收纳。不过这已经是旧的代码隔离方案了，新方法建议使用 Assembly Definition 功能实现。

Artworks文件夹中已经开始体现 “先按模块放，再按类型放” 的思维模式了。Audios、Videos、UI都是功能明确独立的资源，他们都被分类存放。“纹理”、“材质”、“动画”等资源则没有出现在 Artworks 文件夹，因为他们都强绑定“模型”文件，所以按模块化思想，被细分到了Effects和Models文件夹。

模块文件夹

模块文件夹：一个用来存放实现相同功能的资源的文件夹

这是对原则第二点的相关实现。模块文件夹属于用户自定义文件夹，所以命名没什么特别要求：

  1. 其命名能解释模块内容，且满足“命名规范”。
  2. 模块允许嵌套，一个模块可以进一步细分为若干子模块。
1
2
3
4
5
6
+ Effects
  + 拖尾
    - 拖尾1
    - 拖尾2
  - 爆炸
  - 烟雾

上述 Effects 中的所有文件夹（包括子文件）都是自定义的模块文件夹。

类型文件夹

这是对原则第三点的实现。当同目录的同类资源超过两个时就要考虑分类存放，分类时需采用特殊文件夹的形式，常用的特殊文件夹如下：

  • Materials：存放材质球资源（官方）
  • Textures：存放纹理资源（官方）
  • Animations：存放动画相关资源
  • Meshes：存放网格资源
  • Prefabs：存放预制体资源
  • Scripts：存放脚本资源

如果上述文件夹不能满足需求，你完全可以按需定制，基本规则就是以相关资源的类型英文单词为基准，首字母大写加复数的方式命名文件夹即可，例如：Texts（文本文件）。

注意：Meshes不等于模型，因为模型本身可以包含很多内容，例如动画。所以具体要按模型的作用进一步细分，如果只是为了提供动画，应将模型放到Animations，如果是提供显示的网格，才该放到Meshes中。

处理模块依赖

这是对原则第二点的进一步实现。既然采用了模块化，就必然要处理模块化中的依赖问题。具体处理方式有两种：

  1. 若同一文件夹中的资源都存在一些公共依赖的资源，那可将这些被依赖资源按对应类型存放于这些文件的共同父文件夹中。
  2. 若同一文件夹中纯在多个资源，他们之间的依赖资源也各有差异，那可将被依赖资源也作为模块的一种，放入同级文件夹。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
+ Models
  + 角色舞蹈
    动作1.fbx
    动作2.fbx
    动作3.fbx
  + 玩家角色
    + Animations
      跳跃.fbx
      奔跑.fbx
    - 角色1
    + 角色2 
      + Animations：
        角色2普攻.fbx
        角色2大招.fbx
      + Mateirals
        角色2.mat
      + Textures
        角色2.png
      角色2.fbx
  - 非玩家角色
  - 武器
  - 载具
  • Models/玩家角色/Animations：该文件夹为特殊分类文件夹，意味着他不是独立模块。其作用域为同目录所有其他文件夹，这意味着“角色1”、“角色2”会引用其中内容。
  • Models/玩家角色/角色2/Animations：该文件夹也是特殊分类文件夹，其作用域也为当前目录。但当前目录是“角色2”的专用模块文件夹，所以说明该资源仅被“角色2”使用。
  • Models/角色舞蹈：该文件夹非特殊文件夹，而是作为独立模块存放，这意味着他可能被部分同目录其他模块引用，例如“玩家角色”、“非玩家角色”可以使用该资源，但“武器”、“载具”不需要。不过显而易见的的是这里可以将“玩家角色”、“非玩家角色”进一步模块化为“角色”文件夹，这样“角色舞蹈”就可以按第一种依赖处理方式实现了。

凸显模块作用

模块都是为功能而产生，是功能的原始素材，那么最终一定有一个功能的成品。为了突出这一成品的作用，应将其存放到模块文件夹的根目录。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
+ Models
  + 武器
    - Materials
    - Textures
    武器.fbx
  + 载具
    - Materials
    - Textures
    + Meshes
      轮胎.fbx
      车架.fbx
      车架2.fbx
    载具.prefab
    载具2.prefab
+ Effects
  + 爆炸
    - Textures
    + Effects
      爆炸核心.vfx
      爆炸气体.vfx
    + Prefabs
      爆炸.prefab
      爆炸2.prefab
  • Models/武器/武器.fbx：武器文件夹主要提供一个完整的模型显示效果，因此武器.fbx可以作为模块成品放在根目录。
  • Models/武器/载具.prefab、Models/武器/载具2.prefab：虽然是模型文件夹，但提供预制体也没问题，例如你可以借此拼装模型，添加动画，只要确实是成品即可，并且允许存在多个。
  • Effects/爆炸/Prefabs：如果你倾向于收纳也没问题，这样的结构还可以无缝映射到AssetBundle系统，第三方模块中（但这样无法凸显成品，毕竟预制体也可能是内部使用的中间产物，建议到时另建文件夹进行区分）。

清理无效资源

Assets 中只能存放不能删除的文件，任何无效、缓存、可生成文件，不允许放在 Assets。如果是为了防止未来重新使用资源，那应该通过git存储，而不是显示备份。根据实际工作经验，长期不使用的资源，未来也是大概率不会使用的，存放在项目中只会导致臃肿，拖慢编辑器速度。

其他文件规范

该规范实质属于存放规范的一部分，但仅“特效师”、“程序员”、“场景编辑”等需要操作 Unity 的人员需要阅读。

第三方文件夹

项目中大概率会使用第三方提供的功能或资源，这些应统一放在Plugins文件夹（很多插件包导入时自动就收纳到 Plugins 文件夹了，属于一个事实标准）

示例第三方文件夹

例如上图的 Mich-L-Resources 就是第三方资源，其和我们的规范也是对的上的：

  1. Mich-L-Resources 本身就是模块文件夹，体现了“先按模块分”的思想。
  2. Animations、Shaders、Scripts 等都是“再按类型分”的结果。
  3. Characters、HDRP 等则都是根据不同的目的用途，细分的子模块。

Demo 文件夹

实现模块的测试和示例部分

从开发角度来讲，Demo场景应该是必然存在的事物，因为没有场景是没法运行查看效果的。而且功能不是一开发出来就任务结束，开发出来后势必存在后期维护和教授他人使用的阶段。故为了满足上述要求，应尽可能的为模块添加 Demo 文件夹。

Demo 文件夹中配有若干场景（可能也包含这些场景专属的依赖资源），这些场景可以直观呈现模块成品的效果，是一个运行就可以使用的应用案例。如果一个模块添加了Demo文件夹，那么就要在模块内新建一个Sources文件夹收纳原本的文件。

任何开发成员都可能需要建立Demo文件夹（即包括特效等美术师）。但由于程序功能一般复杂，且出错影响大，故对程序员来讲该规范要求更高。例如下方是程序员视角下的一次Demo文件夹使用案例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
+ Scenes
  博物馆.unity
+ Sources
  + TourGuide
    + Demo
      TourGuideTest.unity
      TourGuideTest.cs
    + Sources
      + Models
        - Materials
        - Textures
        导游.fbx 
      + Animations
        待机.fbx
        走路.fbx
        标准人物运动.controller
      - Scripts
      TourGuide.prefab

例如上面的示例中，程序员就提供了其负责的导游模块的示例场景。这有以下好处：

  1. 其本人无需运行完整的应用场景（博物馆.unity），就可以直接借用 TourGuideTest.unity 来快速迭代开发新功能。
  2. 如果程序发生异常，或其他模块发生变动，只用测试 TourGuideTest.unity 就可以确定问题是否与导游模块相关。
  3. 其他需要使用导游模块的程序员，不需要专门咨询原作者，直接查看示例场景就可以直到如何使用。

此外还有一个小细节：模型资源并没有放到 Artworks 中，而是直接放到了 Sources/TourGuide 中，这是基于模块化的思想分配文件夹结构，对于个人开发和内容分发非常方便。以此原理，同样可以把资源分配场景、预制体等目录下。但这种方式也存在一些问题：

  1. 不利于多人开发，工作范围重叠容易冲突。
  2. 造成模块过于臃肿，子文件夹层级过深。
  3. 各层文件夹数量不均，父文件夹失去分类作用。

实际示例

下面是一个多人协作场景下的文件夹结构示例

示例文件夹结构

  • Assets/Artworks/Models/手写板：建模师提供基本的画板模型。
  • Assets/Artworks/Effects/笔迹拖尾：特效师提供了基本的绘制时的画笔拖尾特效。
  • Assets/Sources/DrawingBoard：程序员最终将两者组合实现完整画板功能。
  • Assets/Sources/GameController：可能的额外程序员，用于整合功能模块，实现游戏主逻辑。

基于模块化的思想管理文件夹带来如下好处：

  1. 每个人都可以有专门的工作文件夹，干活互不冲突，效率很高。
  2. 当涉及模块依赖时，由于模块成品被突出放置，立即就能拿到需要的资源。
  3. 因为功能相关文件都放一起且没有多余，移植到其他项目仅需简单移动文件夹即可。

基于分类的思想管理带来如下好处：

  1. 查找资源时可以快速定位到目标位置，而不需要筛选其他文件。
  2. 大部分美术资产都需要预处理（如压缩，mipmap等资源优化），由于同类都放一起，批处理非常方便
  3. 不同功能的同类资源，预处理参数一般是不同的（例如背景音和按钮音效，需采用不同的内存加载策略），故先模块再类型，可以自动筛除掉用途不同的同类资源。
框架使用 > Unity > Unity开发规范
Unity资源规范
https://bdffzi-blog.pages.dev/posts/3831478132.html
作者
BDFFZI
发布于
2026年1月29日
许可协议