小游戏 UI 资源命名规范：透明图、按钮、图标、角色素材

你的项目文件夹里是不是躺着这样的文件：btn_ok.png、button_confirm.png、按钮_确定.png？三种命名风格，三种理解方式，三种协作灾难的开始。

我踩过这个坑。第一个小游戏项目结束时，美术文件夹里有 200 多张素材，一半用的是英文缩写，一半用的是中文直译，还有些干脆叫 新建文件夹 (2).png。找文件像大海捞针，每次改 UI 都要花半天确认哪个是对应的状态。

这篇文章解决一个问题：如何用一套命名公式让你的 UI 资源一目了然。 前缀、类别、功能、状态——四个元素拼起来，就够了。

第一章：命名混乱的真实代价 — 为什么规范如此重要

先说个真实的故事。

去年我和两个朋友做一款休闲小游戏，三人分工：我负责代码，老王做美术，小李写策划。项目进行到第二个月，老王发来一批按钮素材——12 个文件，命名全是 按钮1.png 到 按钮12.png。我问他哪个是确认按钮，哪个是取消按钮，他说：“你看图就知道了。”

那一刻我盯着屏幕上的 12 张图片，每张都是差不多大小的圆角矩形，颜色略有差异。我花了 15 分钟才理清对应关系。后来项目上线，老王改了一批按钮的颜色方案，又发了 12 张新图，这次叫 新按钮1.png 到 新按钮12.png。旧图没删，新图混在一起，我的文件夹里躺着 24 个”按钮”。

腾讯微信游戏团队做过统计：合理的命名能节省 80% 的文件查找时间。 这不是小数字。假设你每天找 10 次素材，每次 3 分钟，一天就是 30 分钟。规范化之后，变成 6 分钟。一个月省下 12 小时，够你写完一个新功能的原型。

更大的麻烦在自动化脚本。我写过一个小工具批量替换按钮素材，逻辑很简单：找所有以 btn_ 开头的 PNG 文件，替换成新版本。结果脚本跑了半天没找到任何文件——因为老王的命名里压根没有 btn_，全是中文。脚本废了，手动改了两个小时。

代码里引用素材名时，问题更明显。看这两行代码：

// 规范命名
this.confirmButton.spriteFrame = assets.get('btn_ok_pressed');

// 无规范命名
this.confirmButton.spriteFrame = assets.get('button2');

第一行一眼就知道是”确认按钮的按下状态”。第二行呢？button2 是什么？你得翻美术文件夹，找到 button2.png，打开看一眼，才知道。每次改 UI 都要这样折腾，代码的可读性直接崩了。

第二章：通用命名公式 — 一套公式解决所有场景

别被”规范”这个词吓到，核心公式其实很简单：

前缀_功能_状态.png

或者更完整一点：

模块_类别_功能_状态@倍率.png

四个元素，从左到右层层递进。举个例子：[email protected]。拆开看：邮件模块、图标类别、搜索功能、按下状态、两倍图。每个部分都有明确的含义。

常用前缀速查表

我整理了 15 个最常见的缩写，来自腾讯云 Cocos Creator 基础教程和智联招聘 UI 设计规范的综合建议：

缩写	全称	适用场景
bg	background	界面背景、弹窗背景
nav	navbar	导航栏元素
tab	tabbar	标签栏图标
btn	button	各种按钮
icon	icon	功能图标、状态图标
img	image	通用图片素材
txt	text	文字图片（如标题）
pop	popup	弹窗相关
bar	bar	进度条、状态条
mask	mask	遮罩层
sep	separator	分隔线
del	delete	删除按钮、图标
add	add	添加按钮、图标
msg	message	提示信息、气泡
logo	logo	Logo 图片

这些缩写有个共同特点：短、好记、一眼能看出是什么。别用 button 用 btn，别用 background 用 bg。越长越容易打错，越长越占字符。

模块特有 vs 通用资源

命名时先想一个问题：这个素材只在一个模块用，还是整个项目都能用？

通用资源：不加模块前缀，直接用类别开头。比如主页的背景图，命名为 bg_home.png，而不是 home_bg.png。因为背景在其他模块也可能复用，按类别归类更容易找到。

模块特有资源：加模块前缀，方便批量处理。比如邮件模块的搜索图标，命名为 mail_icon_search.png。换一套邮件 UI 时，只要搜索 mail_ 前缀，所有相关素材都能一起替换。

带尺寸差异的命名

有时候同一个按钮有大小两个版本。我的做法是在功能后面加尺寸描述：

btn_ok_big_n.png      # 大尺寸确认按钮（正常状态）
btn_ok_small_n.png    # 小尺寸确认按钮（正常状态）

或者用具体的尺寸数字：

btn_ok_128_n.png      # 128px 宽的确认按钮
btn_ok_64_n.png       # 64px 宽的确认按钮

选哪种都行，关键是项目里统一。别一会儿用 big/small，一会儿用数字，一会儿又用 l/s。混乱的根源不是命名规则本身，而是规则不统一。

第三章：按钮与图标命名 — 状态清晰一目了然

按钮是 UI 素材里数量最多、状态最复杂的类型。一个按钮通常有四个状态：正常、按下、选中、禁用。豆瓣 UI 命名规范给出的建议是统一用英文单词或缩写：

状态	全称	缩写	示例
正常	normal	n / def	btn_ok_n.png
悬停	hover	h	btn_ok_h.png
按下	pressed	p / pre	btn_ok_p.png
选中	selected	s / sel	btn_ok_s.png
禁用	disabled	d / dis	btn_ok_d.png

我习惯用单字母缩写，理由很简单：短。btn_ok_n.png 比 btn_ok_normal.png 少了 5 个字符，打字快，看着也清爽。当然，如果你的团队习惯用全称，那就统一用全称。别有的按钮叫 btn_ok_normal，有的叫 btn_ok_n，那样查找时会很麻烦。

按钮命名实战

假设你的项目需要一个”确认”按钮，蓝色圆角风格，四个状态齐全。命名方案：

btn_ok_n.png          # 正常状态
btn_ok_p.png          # 按下状态
btn_ok_s.png          # 选中状态
btn_ok_d.png          # 禁用状态

如果还有红色和绿色两个版本：

btn_blue_ok_n.png     # 蓝色确认按钮（正常）
btn_red_ok_n.png      # 红色确认按钮（正常）
btn_green_ok_n.png    # 绿色确认按钮（正常）

顺序是：类别（btn）+ 颜色（blue）+ 功能（ok）+ 状态（n）。这样排列的好处是文件按字母排序时，同颜色的按钮会聚在一起，方便批量替换。

图标命名：功能优先

图标和按钮的区别在于状态数量。大多数图标只有两个状态：正常和禁用。命名模式：

icon_search_n.png     # 搜索图标（正常）
icon_search_d.png     # 搜索图标（禁用）

图标的命名重点是功能描述要准确。别叫 icon1.png，要叫 icon_search.png 或 icon_delete.png。一看文件名就知道用途，不用打开图片猜。

一个常见的错误示范

我见过这样的命名：button_确认_正常.png。混用了英文前缀、中文功能、中文状态。看起来挺直观，但问题在于：

1. 排序混乱：中文在文件系统里的排序规则不稳定，确认可能排在 取消 前面或后面
2. 脚本兼容性差：批量处理脚本通常用正则匹配，中文字符会让匹配逻辑变复杂
3. 团队协作困难：如果项目后来要支持国际化，所有中文命名都要改

最稳妥的方案是全程用英文，小写，下划线分隔。btn_ok_n.png，简洁、可排序、可正则、可国际化。

第四章：角色素材命名 — 动作帧序列不再混乱

角色素材比 UI 按钮复杂得多。一个主角可能有七八种动作（待机、行走、奔跑、攻击、受击、死亡、跳跃），每种动作又分多个方向（上下左右或八方向），每个方向还有一串动画帧。

我踩过最大的坑是帧数编号。第一次做角色动画时，命名用的单数位：

hero_run_left_1.png
hero_run_left_2.png
hero_run_left_3.png
...
hero_run_left_10.png

看起来挺正常。问题出在文件排序上。打开文件夹一看，hero_run_left_10.png 排在 hero_run_left_1.png 和 hero_run_left_2.png 之间。因为文件系统按字符排序，10 的第一个字符是 1，排在 2 前面。

彻底的灾难。

那之后我强制用两位数编号：

hero_run_left_00.png
hero_run_left_01.png
hero_run_left_02.png
...
hero_run_left_09.png
hero_run_left_10.png

00 到 09 都比 10 小，排序终于正常了。如果你的动画帧数超过 100，就用三位数（000 到 999）。

角色命名公式

完整的角色精灵图命名公式：

角色名_动作_方向_帧数.png

拆开举例：

• hero_idle_down_00.png — 主角_待机_向下_第0帧
• player_run_left_01.png — 玩家_奔跑_向左_第1帧
• enemy_attack_right_02.png — 敌人_攻击_向右_第2帧

动作词汇速查

动作	英文	缩写（可选）
待机	idle	—
行走	walk	—
奔跑	run	—
攻击	attack	atk
受击	hurt	—
死亡	death	die
跳跃	jump	—
施法	cast	—

缩写用不用看你的偏好。atk 比 attack 短，但新成员可能不认识。全称更通用，缩写更简洁。我建议动画帧数不超过 20 的情况下用全称，超过 20 才考虑缩写——文件名太长会让路径显示被截断。

方向标识

最简单的是四方向：up、down、left、right。

八方向可以用编号：0 到 7，约定 0 是向上，1 是右上，以此类推。但编号方案的问题是记不住，每次都要查表。我更喜欢直接用方向名：

hero_attack_up.png
hero_attack_upright.png
hero_attack_right.png
hero_attack_downright.png
hero_attack_down.png
hero_attack_downleft.png
hero_attack_left.png
hero_attack_upleft.png

八方向名称有点长，但读起来不用猜。你的项目如果方向简单（只有四方向或只有左右），用方向名最稳妥。如果方向复杂（八方向甚至更多），编号可能更紧凑。

第五章：Cocos Creator 资源目录结构 — 分类存储提升效率

命名规范解决的是”文件叫什么”的问题。目录结构解决的是”文件放在哪”的问题。两个都要做好，找素材才能真正快起来。

腾讯云 Cocos Creator 基础教程给出的建议结构：

assets/
├── textures/           # 纹理素材
│   ├── ui/             # UI 元素（按钮、进度条）
│   ├── icons/          # 功能图标
│   ├── backgrounds/    # 背景图
│   └── characters/     # 角色精灵图
├── audio/              # 音频文件
│   ├── effects/        # 音效
│   └── music/          # 背景音乐
├── animations/         # 动画剪辑
├── prefabs/            # 预制体
└── scripts/            # TypeScript 脚本

通用 vs 模块特有：分开存放

我踩过的一个坑是把所有素材都塞进 textures/ui/，结果 300 个文件挤在一个文件夹里。打开要等半天，滚动要半天，找文件要半天。

更好的做法是区分”通用资源”和”模块特有资源”：

通用资源放在 textures/ 下的一级子目录，比如 textures/icons/ 存放所有模块都能用的图标。

模块特有资源放在模块专属目录，比如：

assets/
├── modules/
│   ├── login/          # 登录模块
│   │   ├── textures/   # 登录界面专属素材
│   │   ├── prefabs/    # 登录界面预制体
│   │   └── scripts/    # 登录逻辑脚本
│   ├── battle/         # 战斗模块
│   │   ├── textures/   # 战斗界面素材
│   │   ├── prefabs/    # 战斗预制体
│   │   └── scripts/    # 战斗脚本

这样做的好处是换模块时不用翻整个 assets 目录。改战斗界面，只看 modules/battle；改登录界面，只看 modules/login。

别过度细分

过细的分类有时反而添麻烦。我见过有人把 textures/ui/buttons/blue/rounded/ 做了五层目录，每个目录只放两三个文件。找素材时要在目录树里一层层点进去，比直接看文件名还慢。

我的建议是：一级分类就够了，除非某类素材确实数量庞大（比如角色素材超过 50 个精灵图）。textures/ui/ 下放按钮、进度条、分隔线，textures/icons/ 下放图标，textures/backgrounds/ 下放背景。三层以内，一目了然。

预制体和脚本就近放置

预制体（prefabs）和脚本（scripts）最好和对应的素材放在同一层。比如登录界面的按钮预制体放在 modules/login/prefabs/，对应的素材放在 modules/login/textures/。两个目录并列，引用路径短，改动时不用跨目录跳转。

Cocos Creator 的官方文档也提到这个原则：相关文件就近存放，减少跨目录引用。路径越短，项目越清晰，迁移和重构也更方便。

第六章：7 条命名黄金准则 — 来自腾讯游戏团队的经验

腾讯微信游戏团队总结过一套命名黄金准则，我结合自己的实践经验逐条解读。

1. 简明扼要：包含足够细节，不过于繁琐

文件名要传达关键信息，但不能太长。

好例子：btn_ok_n.png — 一眼看得出是按钮、确认功能、正常状态。

坏例子：button_confirm_normal_state_blue_rounded_large.png — 信息太密集，读起来费劲，打字更费劲。

我的做法：控制文件名在 3-5 个单词片段。超过 5 个就考虑删掉次要信息（比如”rounded”这种细节，可以在代码注释里补充）。

2. 层层嵌套：从概括到具体逐层命名

命名顺序要符合认知逻辑：先大类别，再小功能，最后细节。

environment_forest_tree_01.png

解读：环境素材 → 森林场景 → 树木 → 第一个变体。

这样排序的好处是同类别文件自动聚在一起。搜索 environment_forest，所有森林素材都会出现。

3. 合理排序：便于字母顺序查找

前缀的选择会影响排序效果。把最重要的类别放在最前面。

比如角色素材：用 hero_ 开头比用 character_hero_ 开头更好，因为所有主角素材会集中在 h 区域，不用在 c 区域里翻。

4. 格式一致：统一 snake_case 或 camelCase

项目里选定一种格式，全程统一。

我习惯用 snake_case（小写 + 下划线分隔），理由：

• 文件系统兼容性好（不会出现大小写敏感问题）
• 可读性高（单词边界清晰）
• 正则匹配简单（直接用 _ 分隔）

如果团队习惯 camelCase（驼峰命名），那就统一用驼峰。别混用，否则脚本处理会出问题。

5. 统一编号：01/02 或 001/002，避免单数位

这条我在第四章详细说过。单数位编号会导致排序混乱，必须用零填充。

两个规则：

• 帧数不超过 99，用两位数（00 到 99）
• 帧数超过 99，用三位数（000 到 999）

6. 语法一致：统一动词形式

有些动作有两种写法：spin 和 spinning，attack 和 attacking。

选定一种，全程统一。

错误示范：

cha_sonic_spin_01.png
cha_sonic_spinning_02.png

这两个文件是同一个动作，但命名不一致。脚本查找时会漏掉其中一个。

正确示范：

cha_sonic_spin_01.png
cha_sonic_spin_02.png

7. 词形一致：统一拼写标准

英式拼写和美式拼写有时不同：ambience（英式）vs ambiance（美式），colour（英式）vs color（美式）。

选定一种标准（通常建议美式拼写，更通用），项目全程统一。别一会儿 bg_ambience.png，一会儿 bg_ambiance.png，脚本处理会出问题。

第七章：透明图与特殊素材命名技巧

有些 UI 素材比较特殊，命名需要额外考虑。

透明 PNG 的命名

透明背景的 PNG 素材在游戏 UI 里很常见：按钮、图标、叠加效果。命名时可以用 _trans 或 _overlay 后缀标识：

btn_trans_round.png        # 透明圆角按钮（无边框）
icon_overlay_star.png      # 星星叠加图标（用于 badge）

透明素材的特点是看文件名不一定能判断透明度，所以加后缀提醒。使用素材时一眼知道这个文件背景是透明的，不用打开确认。

遮罩层的命名

遮罩（mask）用于裁切图片、实现圆角效果。命名格式：

mask_rounded.png           # 圆角遮罩
mask_circle.png            # 圆形遮罩
mask_gradient.png          # 渐变遮罩

遮罩文件数量通常不多，放在 textures/ui/masks/ 目录或者直接放 textures/ui/ 都行。

多语言资源的命名

国际化项目需要多套文字图片。命名格式：

title_zh.png               # 中文标题
title_en.png               # 英文标题
title_ja.png               # 日文标题

或者用 ISO 语言代码：

btn_start_zh-CN.png        # 简体中文
btn_start_zh-TW.png        # 繁体中文
btn_start_en-US.png        # 美式英文
btn_start_ja-JP.png        # 日文

完整 ISO 代码更准确，但文件名更长。如果你的项目语言版本不超过 5 个，简写（zh/en/ja）就够了。

多倍率适配的命名

移动端游戏需要适配不同屏幕密度：普通屏、高清屏、超高清屏。Cocos Creator 建议用 @1x、@2x、@3x 后缀：

[email protected]            # 普通密度（1 倍）
[email protected]            # 高密度（2 倍）
[email protected]            # 超高密度（3 倍）

这套后缀和 iOS/Android 的标准一致，素材工具（如 TexturePacker）也能自动识别。

注意：倍率后缀放在状态后面，而不是文件名末尾。[email protected] 比 btn_ok@2x_n.png 更清晰——先确认是什么素材（确认按钮正常状态），再确认是什么倍率。

特殊字符的处理

有时候文件名会包含特殊字符，比如空格、括号、中文。我的建议是全部避免。

空格：用下划线替代。btn ok.png → btn_ok.png。

括号：删除或改用数字。btn_ok(1).png → btn_ok_01.png。

中文：统一转英文。按钮_确定.png → btn_ok.png。

特殊字符在跨平台时会出问题。Windows 允许中文文件名，但某些 Linux 服务器不支持。FTP 传输时中文可能乱码。CI/CD 构建时路径解析可能失败。最稳妥的方案是全程英文、小写、无特殊字符。

总结

命名规范的核心公式，其实就是四个元素的排列：前缀、功能、状态、细节。

btn_ok_n.png — 类别（按钮）+ 功能（确认）+ 状态（正常）。hero_run_left_00.png — 角色 + 动作 + 方向 + 帧数。掌握了这个公式，90% 的 UI 素材命名都能解决。

剩下的 10%，是一些细节规则：两位数编号避免排序混乱，全程英文避免跨平台问题，统一缩写避免脚本失效。这些细节不影响命名本身，但决定命名在实际工作中的效率。

你可以从这三件事开始：

1. 检查现有项目：打开美术文件夹，找找有没有命名不规范的文件，用本文的公式重新命名
2. 建立缩写词汇表：和团队约定一套缩写标准（bg/btn/icon/nav），写下来，贴在显眼的地方
3. 整理目录结构：区分通用资源和模块特有资源，别把所有文件塞进同一个文件夹

命名规范不是一次性的工作，而是持续的习惯。习惯了 btn_ok_n.png 的写法，习惯了两位数编号，习惯了全程英文，你的项目文件会越来越清晰，找素材会越来越快。