企业官网建设流程全解析

简介：面向Unity3D初中级开发者的综合素材包，整合了从3D模型、纹理材质、骨骼动画到C#脚本、光照阴影、物理引擎、粒子特效、音频管理和UI系统等游戏开发常用资源。包内共56个文件，以35个js脚本为主体，覆盖角色移动、碰撞检测、物体旋转、菜单界面、分数统计等典型逻辑；另有8个unitypackage资源包，内含音效、火焰特效、场景搭建等可直接导入的示例工程；12个rtf文档和1个txt文件用于说明各模块用法，整体压缩后仅5.71MB，便于下载与分类学习。目前已有2439人学习下载。素材按章节模块化组织，每章围绕一个功能点展开，例如通过Collision脚本实现收集电池、投掷椰子、控制玩家碰撞反馈，配合Mecanim动画系统与UGUI界面，能帮助学习者理解Unity核心组件在实际项目中的配置方式。直接拆解这些文件，可复用成熟的逻辑代码和资源管理思路，快速搭建游戏原型或补充自己的项目模块，对练习Unity3D的脚本编写与资源整合很有帮助。

1. Unity3D素材不是美术资源那么简单：它决定首包体积、加载速度与协作效率

很多开发者第一次意识到 Unity3D素材管理是个问题，通常不是在看文档，而是某天把一个模型压缩包拖进工程，然后开始和紫色材质、丢失引用、动画复位来回拉扯。Unity3D素材不是“美术文件”的统称，它是从导入器、meta 元数据、资源依赖到运行时加载释放这条完整管线的总称。素材管得好，首包体积、加载速度、多人协作都能维持预期；管不好，引擎再强也救不回来。这篇笔记服务于两种人：正在把小 Demo 推向正式项目的开发者，以及团队里需要落地资源规范却没有头绪的同事。我会按导入、目录、加载、排错、自动化检查这条路径，把能直接复用的方案讲清楚。

2. 素材导入的三道闸门：导入器、meta 文件与依赖关系

2.1 导入设置是素材进入引擎后的第一道后处理

把素材拖进 Assets 文件夹，不等于素材已经“进”了项目。Unity 对每种资源类型都有一套导入器（Importer），它把原始文件转成引擎能直接消费的格式，并附上完整的导入参数。很多开发者只在需要改参数时打开 Import Settings，平时完全不看，这其实是把最重要的一个环节当成了黑匣子。

以贴图为例，同一张 PNG 在不同场景下的导入参数差异很大。做 UI 背景时，Texture Type 应该选 Sprite (2D and UI)，Generate Mipmaps 可以关掉，Max Size 按界面实际使用尺寸留出余量即可；做成场景里的漫反射贴图时，则需要保留 Mipmaps，并按目标平台选择压缩格式，移动端通常优先 ASTC 4x4 或 6x6。很多“贴图发糊”的问题，并不是美术原图不行，而是导入参数里的压缩格式没有对准平台，或者 Max Size 被压得太低。

模型和动画的导入设置更关键。FBX 文件导入后，Scale Factor 默认按 1 处理，但有的建模软件以厘米为单位，有的以米为单位，不对齐就会出现模型要么大得穿墙、要么小得看不见。Rig 面板里的 Animation Type 决定 Unity 怎么解析骨骼数据：选 Generic 适合普通骨骼动画，选 Humanoid 会多出一套肌肉映射，能用于动画重定向，但如果美术资源本身没按人形骨骼绑定，强行设 Humanoid 反而会出现姿态错乱。导入阶段多花十分钟确认这些参数，比进场景后反复微调坐标和动画曲线省得多。

还有一个容易忽略的点：对已经导入过的资源单独选中并按 Reimport，会按当前导入参数重新解析一遍。换平台、换渲染管线、升级引擎版本之后，批量重导往往是解决一批“素材看起来不对”的基础操作。但重导前一定要确认导入参数没有在团队里被各人改乱，否则会出现同一张图在不同机器上表现不同的现象。

提示：手动改单个资源参数是最容易出错的环节。后面第 3 章会提到用 Preset 和脚本把导入参数固化，团队协作时一定要把这一步铺开。

2.2 meta 文件：素材身份与引用的锚点

Unity 工程里每个资源和每个文件夹旁边都有一个同名的 .meta 文件，这大概是很多新手最早忽略、后来被坑得最惨的东西。meta 文件里主要记两类信息：一是资源自身的 GUID，二是该资源类型的导入参数。场景、预制体、材质里的引用关系，保存的并不是资源路径，而是 GUID 和 FileID。这意味着资源路径随便改，引用不会断；只要 meta 文件的 GUID 变了，所有引用会瞬间失效。

我见过最典型的事故：某同事在版本库冲突时不小心把美术资源目录里的 .meta 文件删掉了，Unity 重新生成一个新 GUID 的 meta 文件，然后整个场景里所有用旧 GUID 指向该模型的实例全部变成 Missing。更麻烦的是，如果你没意识到是 meta 变了，会以为贴图、模型本身坏了，花大量时间去重导、重命名、重做预制体。恢复的唯一办法，是从版本历史里找回原 meta 文件，放回原目录，让 GUID 重新对上，而不是在编辑器里重新生成。

所以资源规范的第一条铁律就是：meta 文件必须纳管。在 Edit > Project Settings > Editor 面板里，把 Asset Serialization 的 Mode 改为 Force Text，把 Version Control 的 Mode 改为 Visible Meta Files。Force Text 能让资源与 meta 文件以 YAML 文本形式保存，版本合并时冲突可读、可修；Visible Meta Files 则保证 Assets 目录下的每个文件都能看到对应的 .meta 文件，不会在协作时被悄悄漏提。

把 meta 纳入版本管理之后，还要养成一个习惯：重命名或移动资源目录前先和同事同步，提交时把同名的资源与 meta 文件一起提交。Git 合并时如果两边同时改了同一个资源的导入参数，YAML 文本还能做三方合并；如果是二进制序列化模式，冲突基本没有修复余地，只能选择某一方的版本重做。多数团队骂“Unity 协作工程容易坏”，根子不在引擎，而在没有把 meta 文件当一等公民对待。

2.3 依赖关系：先有贴图还是先有材质

素材导入还有一个容易忽略的顺序问题：依赖关系。一个 FBX 模型被导入后，通常不会自带完整的材质和贴图，而是生成默认材质占位；真正可用的材质要等贴图和 Shader 就位后再手动指定。如果先把模型拖进场景，再导入贴图和材质，场景模型上大概率会显示默认的灰色材质，引不到资源。

我把这条依赖链叫做“从下往上补齐”：贴图是最底层，材质引用贴图和 Shader，模型引用材质，预制体再引用模型。按这个顺序逐个导入，每个环节都能在就绪后被正确引用。反过来，先建预制体再补贴图，Unity 虽然会在资源出现时尝试解析引用，但 editor 缓存和版本控制之间经常留出刷新空隙，表现为“明明资源都在，场景里还是 Missing”。

排查依赖问题时，不要靠肉眼猜。选中一个资源后，可以在 Inspector 右下角看到依赖信息窗口，但更彻底的办法是用 AssetDatabase.GetDependencies(path, true) 拿到完整的依赖树。我一般会在排查“模型是完整的但导入后颜色全错”这类问题时先跑一遍，看模型依赖的材质、贴图、Shader 是否全部存在于工程内。只要依赖列表里出现某个路径指向不存在的资源，问题就定位了，重新指向即可。

依赖关系还影响工程的加载效率。同一个贴图被多个材质引用、同一个材质被多个预制体引用，这本身没问题；怕的是不同目录下存在内容相同的贴图副本，各引各的，最终在运行时被重复加载进内存。这种问题在资源管理器端看不到，只有在构建报告或者运行时 Profiler 里才发现内存里有两份同名纹理。所以我一直建议，工程入口就要先立目录规范，避免靠“复制一份进去”来解决问题。

3. 把素材管线从默认改成可控：目录规划、命名约定与校验脚本

3.1 目录不是分类学，是加载策略的影子

第一次建 Unity 工程时，多数人只会自动生成 Assets 下的几个默认文件夹，然后随用随建。等资源到了几百个，才发现目录结构直接决定了加载策略怎么做。Resources 目录下的所有东西会被无条件打进安装包，StreamingAssets 会原样拷贝，Art 目录可以放工程内使用的原始美术资产，但如果里面没有任何加载器引用，它也会被工程扫描并参与构建大小统计。

我一般会建议团队先定一套通用目录骨架，至少把美术、音频、预制体、脚本、配置分开：

Assets/ ├─ Art/ │ ├─ Characters/ │ ├─ Environment/ │ ├─ Props/ │ ├─ UI/ │ └─ Effects/ ├─ Audio/ │ ├─ BGM/ │ ├─ SFX/ │ └─ Voice/ ├─ Prefabs/ ├─ Scripts/ ├─ Settings/ └─ Resources/

这里的关键点是：Art、Audio、Prefabs 是“源资产目录”，Resources 是“运行时加载目录”。源资产目录里的内容不一定会被直接打包，它们可能被 Addressables 按组引用、被预制体引用、被构建时收集；Resources 目录则意味着“不引用也会被打进去”。所以不要把所有东西都往 Resources 里塞，也不要把贴图、模型直接放在根目录，否则构建报告出来后你根本判断不了哪些资源来自哪里。

目录命名我强烈建议统一用小写开头的大驼峰或者全小写加下划线，比如 Characters、environment_v2 这种风格二选一。不要用中文目录名，部分工具链、第三方打包脚本和 CI 环境对非 ASCII 路径的处理并不稳定，这个坑我在本地开发时看不出问题，一上构建机就翻车。目录一旦定下来，宁可在前期多讨论几天，也不要上线后再大规模重命名。

注意：移动、重命名目录在 Unity 里不是文件操作，是资源引用操作。建议用编辑器 Project 窗口拖动，而不是用资源管理器操作，否则 meta 文件挪动后引用可能错乱。

3.2 命名约定：让脚本和同事都能读懂资产

目录只是第一层约束，真正让素材管线可控的是命名约定。没有约定时，同一个目录下会出现 final_v2_最终版 这种文件，脚本无法稳定匹配资源，同事也不知道哪个才是正式使用的资源。我通常采用前缀 + 语义名的方式：贴图用 T_ 开头，材质用 M_，预制体用 Pre_，模型用 FBX_，音频用 A_，特效材质用 VFX_。这样在批量搜索、写加载命名规则、做资源校验时，一眼就能判断类型。

前缀约定更大的价值是配合导入预设（Preset）使用。在 Unity 里可以创建 .preset 文件，把一组导入参数保存下来，然后指定它作用于哪个类型的资源或哪个目录。新导入的资源会自动套用预设参数，不需要逐个手动改。比如 UI 目录下所有图片自动关闭 Mipmap、压缩格式设为 Sprite 专用；场景贴图目录自动开启 Mipmap、压缩格式设为 ASTC。这个机制能彻底解决“默认导入参数不适合项目”的问题。

具体做法是：先手动把一个资源的导入参数调到理想状态，然后在 Inspector 右上角的 Preset 面板里点 Save As，生成 preset 文件；再到 Project Settings 或资源目录上配置它对这些路径生效。注意，preset 不是“在导入后修正”，而是在导入那一刻就套用，所以对批量导入新资源特别有效。已经导入过的老资源不会因新建 preset 自动变更，需要批量选中后重新应用，或者执行一次 Reimport。

命名约定虽然不像代码那样直接影响运行逻辑，但它决定了资源校验脚本怎么写。比如脚本要统计“目录下有没有重复贴图”，如果文件命名没有规则，只能靠哈希比较；如果事先抽离出 T_ 前缀和资源 ID，脚本就能按规则做判断。还有一点容易被忽视：Prefab 命名最好与它所引用的核心模型或 UI 资源保持一致，比如 Pre_PlayerTank 应该引用 FBX_PlayerTank 和 T_PlayerTank_Diffuse，否则排查预制体引用链时要在多个目录之间跳来跳去。

3.3 用编辑器脚本做一次资产静态体检

规范靠人盯是盯不住的，我一般会写一个编辑器脚本，把资源体检做成菜单命令。下面这个脚本检查所有材质是否引用了有效的 Shader——素材管理里最常见、最隐蔽的问题之一：

using System.Collections.Generic; using UnityEditor; using UnityEngine; public class AssetHealthChecker { [MenuItem("Tools/素材健康扫描/检查材质Shader")] public static void Run() { string[] guids = AssetDatabase.FindAssets("t:Material", new[] { "Assets" }); List<string> broken = new List<string>(); foreach (string guid in guids) { string materialPath = AssetDatabase.GUIDToAssetPath(guid); Material mat = AssetDatabase.LoadAssetAtPath<Material>(materialPath); if (mat == null) continue; Shader shader = mat.shader; if (shader == null || shader.name.Contains("InternalErrorShader")) { broken.Add(materialPath + " -> Shader 缺失或为引擎错误Shader"); } } if (broken.Count > 0) { Debug.LogError("发现 " + broken.Count + " 个问题材质：\n" + string.Join("\n", broken)); } else { Debug.Log("素材体检通过：未发现 Shader 引用异常。"); } } }

这段脚本里三个 API 是素材管理的核心：AssetDatabase.FindAssets 按类型和目录过滤，返回 GUID 数组；GUIDToAssetPath 把 GUID 转成 Assets 下的相对路径；LoadAssetAtPath 泛型加载出真实资源。注意检查 Missing Shader 时不能只判断 shader == null，因为 Unity 会用内置的 Hidden/InternalErrorShader 替换缺失引用，必须把名称也纳入判断。

脚本要放在 Editor 文件夹下，或者项目里专门建一个 Editor 程序集，否则发布时会带着编辑器 API 一起进包。运行时，点击菜单 Tools > 素材健康扫描 > 检查材质Shader 就能看到结果。这个命令只做静态检查，不修改任何资源，所以可以放心跑，不会因为一次体检改变工程状态。

在它的基础上很容易扩展出更多检查项：遍历目录找出超过设定 Max Size 的贴图、扫描同名重复资源、检查预制体是否存在失效引用。每加一项，就相当于把一条“可能翻车的经验”固化成了自动检查。后面第 6 章我会给出一个更完整的贴图尺寸扫描脚本，并说明怎么把它挂到 CI 上作为构建门禁。

4. 素材加载的两种主流姿势：Resources 与 Addressables 到底怎么选

4.1 Resources：简单直接，但处处是隐形成本

Resources.Load 是很多新手接触的第一个运行时加载 API，因为它的使用门槛最低：把资源放进 Resources 目录，代码一行就能同步加载出对象。但这个简单背后有三个隐形成本。第一，Resources 目录下的所有资源，无论运行时是否被用到，都会被无条件打进安装包，包体膨胀往往从这里开始。第二，Resources.Load 是同步加载，大资源直接卡主线程，场景切换时掉帧是常客。第三，它不支持热更新，后续想替换内容只能发整包，做不了运营期的小步迭代。

我见过不少项目，前期图省事用 Resources，一两个月后资源量上来就后悔。所以我对 Resources 的定位很明确：适合工具型应用、单机演示、内容基本不变的小项目。如果你做的产品必须长期更新玩法、新增皮肤或关卡，不要把它当主力加载方案。可以把它保留为静态配置、多语言表这类低频少量资源的加载口，但不要让角色模型、场景贴图这类大头住在 Resources 里。

还要提醒一个细节：工程里可以有多个 Resources 文件夹，但最终构建时它们会被合并为一个整体，同名资源会发生覆盖。这个行为在编辑器里不容易暴露，因为在 Project 搜索时你会看到多个同名文件，运行时却只会加载到某一个。为了避免这种“同名的另一半去哪了”的玄学问题，我要求在 Resources 目录里不允许出现同名文件，并通过脚本在构建前检查一遍。

4.2 Addressables：让加载和卸载都变成显式行为

Addressables 是当前大型项目的主流选择，它在 AssetBundle 之上提供了一整套可寻址资源系统。核心思想是给资源一个地址，异步加载、引用计数、自动或手动释放，并按分组决定打进哪个包里。相比自己管理 AssetBundle 的依赖和卸载时机，Addressables 把这层复杂度封装掉了，代价是引入了一段学习曲线和一个异步生命周期。

下面是一段典型的可寻址资源加载流程：

using UnityEngine; using UnityEngine.AddressableAssets; using UnityEngine.ResourceManagement.AsyncOperations; public class AssetLoaderExample : MonoBehaviour { public AssetReference prefabReference; private AsyncOperationHandle<GameObject> handle; public void LoadPrefab() { if (!prefabReference.RuntimeKeyIsValid()) { Debug.LogWarning("资源未配置或地址无效"); return; } handle = Addressables.LoadAssetAsync<GameObject>(prefabReference); handle.Completed += op => { if (op.Status == AsyncOperationStatus.Succeeded) { Debug.Log("资源加载成功: " + op.Result.name); } else { Debug.LogError("资源加载失败: " + op.OperationException); } }; } private void OnDestroy() { if (handle.IsValid()) { Addressables.Release(handle); } } }

代码里 AssetReference 允许在 Inspector 直接拖一个 Addressable 资源；RuntimeKeyIsValid 用来判断引用是否已经配置；LoadAssetAsync 异步加载，成功回调里拿到的是资源本体。这里最容易踩的坑是 Release 时机。如果加载后只是查看，OnDestroy 里释放没有太大问题；但如果你用 op.Result 实例化了一个对象，这个对象销毁时应该配合 Addressables.ReleaseInstance 来释放，而不是直接释放原始 handle，否则引用计数会失控。

Addressables 的分组策略决定了你的包怎么切分。在 Addressables Groups 窗口里，每个 Group 对应 Assets 列表，组属性里可以指定构建路径、加载路径、压缩方式。我一般会把角色、场景、UI、音频拆成独立组，按功能模块而不是资源类型分组，这样后续热更新某个功能时，只下发对应组即可。构建后生成的 catalog 文件会记录所有地址与资源包的映射关系，运行时更新目录就能拿到最新版本。

4.3 选型：我一般会按这三个问题做决策

要不要用 Resources、AssetBundle 还是 Addressables，团队里经常吵，我一般会拿三个问题过一遍：产品内容是否需要持续更新？包体和内存压力是不是当前的主要矛盾？团队成员是否熟悉异步加载与失败处理？三个问题的答案组合起来，选型基本就清楚了。

如果内容基本不变，比如工具型应用、单机创意 Demo，用 Resources 足够，省下时间去做玩法。如果要做较为复杂的运营期内容更新，直接上 Addressables，不要自己做 AssetBundle 管理。AssetBundle 是底层方案，适合有专门基建能力和时间打磨的团队，小团队自己封装很容易在依赖管理上踩到死坑。

内存控制上，Resources 基本没有细粒度可言，资源常驻与否不受你控制；Addressables 每次加载都会增加引用计数，配合 Release 可以把不用的资源及时卸载，这在频繁切换场景的玩法里非常重要。另外 Addressables 的 Analyze 功能可以查重复资源、错误引用，这些自动化检查是团队持续维护素材健康度的基础。

不要把选型当成一次性的技术决定。项目早期用 Resources 做原型没问题，但要预留切到 Addressables 的准备，比如所有资源访问都走一个自定义加载接口，不要在业务代码里到处直接 Resources.Load。这样后期迁移时，只需要把内部实现替换，不需要改业务逻辑，成本会低很多。

5. 素材管理避坑指南：五个翻车现场的现象、原因与解决方案

5.1 模型发紫发粉：材质贴图全部失效

现象：FBX 模型导入场景后，网格正常，表面材质却呈现大片紫色或粉红色。这是引擎找不到有效 Shader 时的默认表现，不是美术资源真的坏了。

原因有三个分支：一是模型依赖的 Shader 没有随资源包一起导入，比如用到了某个第三方着色器；二是工程切换过渲染管线，内置管线的 Standard Shader 在 URP 工程里不再被识别；三是材质引用的贴图路径失效，Shader 找到了但贴图没找到，表现也接近紫色。排查时先分开看：材质是否缺失 Shader，材质依赖的贴图是否都在，渲染管线是否切换过。

解决：选中模型对应的材质，先看 Shader 下拉框是否显示为 Missing。缺失的话重导模型、重新指定材质；如果是渲染管线切换导致的，用编辑器的渲染转换工具把旧材质批量升级到新管线，再统一重导一次。不要手动一张图一张图重指，那样既慢又容易漏。用 AssetDatabase.GetDependencies 查一下材质依赖，能快速定位到底是贴图缺失还是 Shader 缺失。

5.2 合并分支时 meta 文件冲突，场景引用全面错乱

现象：两个分支各自新增了同名的美术资源，合并后场景或预制体里的引用大量变成 Missing，打开项目看到一堆资源带着重复的 .meta 文件。这是非常典型且影响恶劣的协作灾难。

原因：Unity 场景里保存的是 GUID 而不是路径。两边各自在本地生成了同一个相对路径资源的不同 GUID，合并时如果 meta 文件冲突被错误解决，最终只有一个 GUID 存活，另一个资源的全部引用链断裂。如果资源被大量场景引用，整体表现为“工程被改坏了”。

解决：第一步，把版本控制设置为 Visible Meta Files 和 Force Text，让冲突可视。第二步，合并且冲突时，保留被引用更多的那份 GUID，把另一份引用全部替换为保留的 GUID。第三步，处理完冲突后全局搜索旧 GUID，逐一替换到新 GUID，再执行一次资源重导。平时要养成习惯：大范围重命名资源目录之前先与团队同步，避免两边同时动同一段路径。

5.3 动画导入后骨骼姿态复位，关键帧全部丢失

现象：FBX 导入后模型网格正常，Animation Clip 也能选中，但播放时模型完全不动，或者骨骼姿态全部回到 T-Pose，关键帧在预览里根本看不到。

原因：Rig 面板的 Animation Type 与实际数据不匹配。如果模型是普通骨骼动画，却被设成 Humanoid，Unity 会尝试做肌肉映射，映射失败后动画数据被剥离；反过来说，如果是人类角色动画，却设成 Generic，重定向能力和部分曲线也会异常。另一个常见原因是开启了 Optimize Game Objects，Unity 把骨骼节点全部移除，运行时动画系统找不到目标骨骼。

解决：打开 FBX 的 Rig 页面，按实际模型类型设置 Animation Type。普通 NPC、动物、机械用 Generic；需要复用人类动画的用 Humanoid，并检查 Avatar 是否成功生成。如果项目代码要访问骨骼节点，比如武器挂点、头部跟随，就不要勾 Optimize Game Objects，或者在 Extra Exposed Transforms 里把需要的骨骼手动加回来。改完参数后 Reimport，再看动画是否恢复。

5.4 图集打包后贴图发糊或者有缝隙

现象：2D 游戏用了 Sprite Atlas 后，运行时相邻 UI 元素边缘出现半透明线条，或者小图放大后明显发糊。

原因：小图被填进大图集时，边缘像素和相邻图片的采样区域发生渗色，这是 GPU 线性过滤导致的，本质是图集没有给每张小图留出足够 padding。另一个原因是图集内贴图的 Max Size 偏低，图集被迫缩小，细节丢失。

解决：在 Sprite Atlas 的 Inspector 里把 Padding 调到 4 像素，给边缘留采样缓冲区。贴图的 Texture Type 务必设为 Sprite，Filter Mode 用 Bilinear 或 Trilinear 时注意边缘处理，有些项目为了省一条 GPU 指令会关 Mipmap，但 UI 高频缩放还是保留 Mipmap 更稳。压缩格式要选平台支持的 Alpha 压缩格式，不然透明边缘会出现色差。出现缝隙时，最直接的验证方法是把 Padding 从 4 调到 8 重打一次图集，如果缝隙消失，就是 Padding 不够。

5.5 首包体积膨胀，一张贴图吃掉几十 MB

现象：构建出来的包体比预期大很多，诊断工具里发现某个目录下的贴图动辄 2048 甚至更高，单个文件体积占了几十 MB，而它在界面上可能只是一张 500 像素宽的背景图。

原因：贴图导入时 Max Size 默认 2048，配合无压缩格式，体积会非常惊人。美术为了质感在原始文件里做成 4096，但运行时根本不会以完整分辨率显示。如果压缩格式选成 RGBA 32bit，又不开压缩，体积再翻一倍。

解决：用导入预设给不同类型资源定 Max Size：大场景背景贴图给 2048，UI 图给 1024 或按实际尺寸 2 倍，小图标给 256 或以像素对齐。压缩格式在移动端优先 ASTC，桌面端可用 BC7。然后执行一次全量重导。重点是从入口控制，而不是在问题出现后一张张改，因为人的记忆不可靠，预设才是可靠的。配合 Addressables 的 Analyze 或构建报告看最终打包结果，确认没有资源重复进入多个组。

注意：解决体积问题要按压缩收益排序。先压贴图纹理格式，再调音频采样率和压缩格式，最后才是删资源。顺序反了容易误删仍在使用的素材。

6. 用 AssetDatabase 写一个素材健康扫描器：从编辑器菜单挂到 CI 门禁

6.1 一个能查出三类问题的扫描脚本

前面第 3 章的脚本只查材质 Shader，实际项目里我建议再做一张更细的贴图扫描。下面这段脚本会遍历指定目录下所有贴图资源，把“原始尺寸不大却设置了过大的 Max Size”的资产找出来，这类浪费在构建里最常见：

using System.Collections.Generic; using UnityEditor; using UnityEngine; public static class AssetAudit { [MenuItem("Tools/素材健康扫描/贴图尺寸检查")] public static void ScanTextureSize() { string[] guids = AssetDatabase.FindAssets("t:Texture2D", new[] { "Assets/GameArt" }); List<string> overSized = new List<string>(); foreach (string guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); TextureImporter importer = AssetImporter.GetAtPath(path) as TextureImporter; if (importer == null) continue; Texture2D tex = AssetDatabase.LoadAssetAtPath<Texture2D>(path); if (tex == null) continue; int maxEdge = Mathf.Max(tex.width, tex.height); if (maxEdge <= 1024 && importer.maxTextureSize > 1024) { overSized.Add(path + " 原始尺寸 " + tex.width + "x" + tex.height + "，Max Size 设置为 " + importer.maxTextureSize); } } if (overSized.Count > 0) { Debug.LogError("以下贴图导入尺寸偏大：\n" + string.Join("\n", overSized)); } else { Debug.Log("贴图尺寸检查通过。"); } } }

TextureImporter 是贴图导入器的编辑态 API，GetAtPath 拿到后可以直接读取 maxTextureSize；LoadAssetAtPath 加载出实际纹理，读取原始像素尺寸。脚本的逻辑很简单：原始长边不超过 1024，导入设置却允许 2048，说明资源在构建时被无意义放大。类似的逻辑可以扩展到音频采样率、模型面数、重复文件名检查，每一条都是把人工经验固化成规则。

编辑器菜单适合本地开发时手动触发，但它真正有价值的地方在于变成 CI 门禁。这样每次提交代码前或者每个夜间构建里，脚本会自动扫一遍素材健康度，有问题直接让构建失败，而不是发布后才发现包体异常或素材缺失。

6.2 让扫描结果变成构建前置检查

把上面的方法挂到批处理模式很简单，在本地命令行执行一次相当于运行编辑器的无窗口模式，并调用指定静态方法。命令大致如下：

unity-editor -batchmode -projectPath "$(pwd)" -executeMethod AssetAudit.ScanTextureSize -quit -logFile build.log

注意这里的 unity-editor 只是占位，实际命令路径取决于安装位置和所在环境。关键参数有三个：batchmode 表示进入批处理模式，不弹窗口；executeMethod 后面是静态方法全名，方法要声明为 public 且无参数；quit 表示执行完立即退出。如果方法内部抛了异常，进程会返回非 0 退出码，CI 里读到非 0 就把这次构建判定为失败。

写批处理扫描脚本时有一个限制要记住：不要在里面调用 EditorUtility.DisplayDialog 这类弹窗 API，批处理模式没有可交互界面，弹窗会卡住流程直到超时。脚本里也不要依赖某个场景打开后才能访问的数据，批处理模式默认不加载任何场景，所有检查要基于 AssetDatabase 能直接访问的资源内容。日志统一写到固定文件，CI 失败时直接把文件尾部的 Error 行抓出来，排错速度会快很多。

我现在做新项目时已经习惯把“资源扫描通过”写进构建前置条件里。以前带过一个项目，发布后才发现角色立绘贴图被 2048 全尺寸打进了安装包，问题看着不大，但换来的是首包体积和加载内存的双重超标。那次之后我花了一个小时把这些检查脚本补齐，从那以后发版前再也没有手动翻过资源列表。素材管理做得好不好，不看导入时有多顺利，而看问题能不能在发版前被规则拦下来。希望帮到你。

本文还有配套的精品资源，点击获取