企业官网建设流程全解析

1. 为什么你需要一套资源导入设置脚本

干Unity这行久了，你会发现一个特别扎心的现象：美术和策划交上来的资源，导入设置永远跟你期望的不一样。纹理压缩格式乱选、音源没关循环、FBX的缩放系数是1.01、骨骼动画Scale Uniformly没勾、Sprite的Pixels Per Unit五花八门。你要是靠人工一个一个去改，且不说效果，光是来回沟通的成本就够你喝一壶。哪怕项目里已经定了规范文档，但人总是会忘的，新来的同事也未必有耐心逐条读。

所以我从一开始就强调：资源导入设置脚本不是锦上添花，而是Unity项目的刚需，尤其是中大型项目、多人协作项目，以及任何一个打算长期维护的私人项目。它本质上是把“导入资源的规则”用代码固化下来，让Unity在资源进入工程的那一刻就自动执行你的设置策略。

这套方案解决的核心问题有三个：

1. 一致性：同一张纹理、同一个FBX，不管是谁导入的、什么时间导入的，最终设置都一样，彻底消除人为差异。
2. 自动化：资源一进Project窗口就自动处理，不需要任何人手动去调Inspector。
3. 可维护：规范写在代码里，代码放在版本控制里，规则变更走Code Review，团队里每一个人都能看到规则的来龙去脉。

这篇笔记我会从一个实际项目的角度，把AssetPostprocessor这套东西从原理到实战、从坑到经验完整过一遍，包括纹理、模型、音频的导入策略，以及团队协作场景里我踩过的那些坑。很多内容是我在多个项目里反复验证过的，可以直接抄走用。

2. Unity资源导入管线的核心原理

2.1 AssetPostprocessor 到底在什么时候被调用

要理解导入脚本，先得理解Unity的导入管线。Unity的AssetDatabase在检测到资源文件变化（新增、修改、删除、移动、Meta变更）后，会触发对应的回调。AssetPostprocessor就是Unity给开发者留的一扇门，让你能在导入流程的特定阶段插入自定义逻辑。

回调的顺序是固定的，这也是很多新手容易搞错的地方：

1. 资源开始导入：OnPreprocess相关的方法触发，比如纹理有OnPreprocessTexture、模型有OnPreprocessModel、音频有OnPreprocessAudio。这个阶段你是去修改导入设置的，改的是AssetImporter上的参数。
2. 资源导入完成：OnPostprocess系列方法触发，此时导入引擎已经按你的设置把资源导入了，你可以读取到最终的Texture、Mesh、AnimationClip等对象，做一些校验或者数据读写。
3. 依赖资源更新：OnPostprocessAllAssets在所有资源导入完成后触发，适合做跨资源的批处理。

这里有一个关键认知：你必须在Preprocess阶段修改Importer设置，而不是在Postprocess阶段再回头改。因为引擎在Postprocess阶段已经生成了导入结果，你再改Importer参数，除非强制Reimport，否则不会生效。我见过不少人把设置逻辑写在OnPostprocessTexture里，然后发现改了没反应，百思不得其解，其实就是对管线阶段的理解不到位。

2.2 为什么推荐用 AssetImporter 而不是直接操作资源文件

有些刚上手的同学会想：我是不是可以直接在资源文件里写设置？比如把纹理的meta文件改掉？理论上可行，但极其不推荐。原因是Unity的资源导入信息是存在.meta文件里的，你手动改meta格式，很容易破坏Unity的元数据，轻则导入报错，重则资源丢失引用。

而AssetPostprocessor是在引擎内部的导入流程里操作Importer对象，Unity会自行处理meta的同步问题。你只管写规则，序列化的事交给引擎。这就是“官方给你开好的门，你偏要去翻窗户”的区别。

2.3 脚本生命周期和初始化要点

AssetPostprocessor脚本不需要挂到任何GameObject上，也不需要手动初始化。你只要把它丢到项目的Editor目录下，Unity在资源导入时就会自动实例化并调用。注意是Editor目录，不是普通脚本目录，否则脚本会打进运行时程序集，导致编辑器相关API没法用，还会报错。

脚本文件名和类名保持一致，继承AssetPostprocessor，然后在需要处理的回调里写业务逻辑。Unity对脚本放置位置有要求：必须在Editor文件夹下，包括子文件夹，因为AssetPostprocessor属于编辑器命名空间UnityEditor。

#if UNITY_EDITOR using UnityEditor; using UnityEngine; public class TextureImportProcessor : AssetPostprocessor { private void OnPreprocessTexture() { // 在这里修改纹理导入设置 } } #endif

这里有个小细节：OnPreprocessTexture这一类方法是私有的，Unity通过反射机制调用，所以不需要写public。你只要方法签名正确就行。

3. 写一套真正能用的资源导入设置脚本

3.1 代码结构设计：按资源类型拆模块

我强烈建议不要把所有的导入逻辑塞进一个文件里。项目初期你可能觉得就几百行代码，塞一起既能看又不复杂，但等你加了平台差异化配置、加了命名校验、加了依赖检查之后，那文件会长到几千行，维护起来非常痛苦。

我推荐的做法是按资源类型拆分：

Editor/ ├── ImportSettings/ │ ├── TextureImportProcessor.cs │ ├── ModelImportProcessor.cs │ ├── AudioImportProcessor.cs │ ├── FontImportProcessor.cs │ ├── CommonImportValidator.cs │ └── ImportSettingsConfig.cs

每个文件只负责一种资源类型的导入策略，公共的判断逻辑（比如是否属于UI资源、是否属于角色模型）放到Common模块或者一个静态配置类里。这样不同模块的职责边界清晰，后续谁负责纹理规范谁改Texture那个文件，互不干扰。

3.2 纹理导入：按目录划分规则是最常用的策略

纹理是项目中资源量最大、最容易出问题的类型。因为同样一张图片，UI图集和3D贴图的设置逻辑完全不一样。UI图要开Sprite模式、要支持图集打包；3D模型的Albedo贴图可能只需要RGBA32无压缩，带透明通道的树叶贴图又要RGBA Compressed。

所以纹理导入脚本的核心是目录路由。我在项目里用了assetPath判断资源所在的目录树，再根据目录挂载对应的规则：

private void OnPreprocessTexture() { string lowerPath = assetPath.ToLower(); if (lowerPath.Contains("/ui/")) ApplyUISettings(); else if (lowerPath.Contains("/characters/")) ApplyCharacterSettings(); else if (lowerPath.Contains("/terrain/")) ApplyTerrainSettings(); else ApplyDefaultSettings(); }

这里有一个非常关键的注意事项：判断路径时一定要用ToLower做归一化。因为在Windows上路径不区分大小写，美术的文件夹叫UI还是ui完全看心情，而你写规则时不可能把所有大小写组合都列一遍。

再来看UI纹理的具体设置，这里涉及的内容比较多，我直接贴一套我项目里在用的完整方法：

private void ApplyUISettings() { TextureImporter importer = (TextureImporter)assetImporter; importer.textureType = TextureImporterType.Sprite; importer.spriteImportMode = SpriteImportMode.Single; importer.mipmapEnabled = false; importer.alphaIsTransparency = true; importer.spritePixelsPerUnit = 100; importer.textureCompression = TextureImporterCompression.Uncompressed; importer.filterMode = FilterMode.Bilinear; importer.wrapMode = TextureWrapMode.Clamp; importer.maxTextureSize = 2048; TextureImporterSettings settings = new TextureImporterSettings(); importer.ReadTextureSettings(settings); settings.spriteMeshType = SpriteMeshType.Tight; importer.SetTextureSettings(settings); }

逐个说下为什么这样设：

• mipmapEnabled = false：UI图片是摆在固定分辨率屏幕上的，不需要Mipmap。关闭Mipmap至少能省三分之一的显存，对UI来说是无损优化。
• Uncompressed压缩：UI图片如果要参与图集打包，打包阶段会再处理压缩格式。如果在导入阶段就做了有损压缩，图集再压一遍等于二次有损，画质会变差。所以这里保持不压缩，把压缩的决定权交给图集系统。
• Bilinear+Clamp：这是UI的常用组合。Bilinear保证缩放时平滑，Clamp防止边缘采样到相邻像素导致描边异常。

在纹理导入里还有两个高频需求，一是带透明通道的贴图，二是法线贴图。法线贴图必须设置textureType = TextureImporterType.NormalMap，否则光照计算会得到完全错误的结果。这个属于硬性规则，项目里只要检测到贴图文件名包含_normal或_n后缀，就必须强制设为法线贴图，不管你导入的是什么。

if (assetPath.Contains("_normal") || assetPath.Contains("_n") || assetPath.ToLower().EndsWith("_normal.png")) { importer.textureType = TextureImporterType.NormalMap; importer.textureCompression = TextureImporterCompression.Compressed; }

有些美术同事会把法线贴图命名成_nmap、_nrm、_nor，你到底认哪些后缀，需要在项目规范文档里写清楚，并且代码和文档同步维护。

3.3 模型导入：FBX设置里最容易踩的隐藏坑

模型的导入设置比纹理复杂一个量级，因为涉及坐标系、缩放、骨骼、动画等多个维度。我实际项目里见过最多的模型问题，集中在ModelImporter的几个参数上。

先看一下模型导入的核心逻辑：

private void OnPreprocessModel() { ModelImporter importer = (ModelImporter)assetImporter; // 关键轴转换 importer.globalScale = 1f; // 归一化 importer.useFileScale = true; // 动画 if (assetPath.Contains("@")) { importer.animationType = ModelImporterAnimationType.Human; importer.importAnimation = true; } else { importer.importAnimation = false; } // 材质 importer.materialLocation = ModelImporterMaterialLocation.External; importer.materialSearch = ModelImporterMaterialSearch.RecursiveUp; importer.importBlendShapes = true; // 命名规范校验，如果模型名字不符合规则直接LogWarning if (!assetPath.EndsWith(".fbx", System.StringComparison.OrdinalIgnoreCase)) Debug.LogWarning($"[ModelImporter] 非FBX模型文件: {assetPath}"); }

这里有几个关键点展开讲：

第一，globalScale千万不要乱设。我见过有的项目为了“统一单位”强制把globalScale设为0.01，直接导致所有模型在引擎里小得看不见。globalScale的实际作用是把美术软件里的单位换算成Unity的单位。3ds Max和Maya默认单位不同，3ds Max通常用英寸或厘米，Maya用厘米。正确的做法是先确认建模软件单位和Unity的换算率，如果建模师都以厘米为单位建模，Unity的默认单位也是米，那导入时通常globalScale=1配合useFileScale=true就能得到正确结果，根本不用手动改。

第二，动画分离文件命名。Unity的规范是用@符号把模型和动画分开。比如角色模型叫Player.fbx，动画文件叫Player@Run.fbx。在导入脚本里检测@就能知道这个文件是纯动画文件还是模型文件。动画文件导入时应该关掉网格导入，meshImport不开，可以省很多内存。但是注意，Unity的ModelImporter在检测到纯动画FBX时，importAnimation设为true是常规操作，而importMeshes（网格导入）其实也要设置，默认是true。如果你一个动画文件有几十个Mesh，那内存占用很夸张，所以在动画文件里显式关闭网格导入：

if (assetPath.Contains("@")) { importer.importAnimation = true; importer.importMesh = false; // 动画文件不导网格 }

第三，材质搜索策略。materialLocation设External之后，Unity会尝试在外部搜索材质球文件来匹配模型的材质。RecursiveUp表示从模型同级目录向上逐层搜索，这是相对友好的策略。如果设置自动搜索失败，模型会生成依赖内置Shader的材质，运行时显示粉色。这个坑我在新项目里踩得比较多，因为美术给的模型文件夹结构往往很乱。

第四，BlendShape必须显式打开。很多项目的捏脸、表情动画靠BlendShape。但Unity的默认导入设置里BlendShape是关的（具体版本不同，新版默认开了，老版本不是）。如果你不在脚本里强制importBlendShapes = true，模型能正常导入，表情就是基础姿势。美术那边看着正常，引擎里动不了，排查起来极其痛苦。无论模型是否真的有BlendShape，这个开关统一设为true成本极低。

3.4 音频导入：处理再编辑项目容易忽略的性能点

音频资源简单，但特别容易被忽略。我见过有些项目几百个音频全用Vorbis压缩，加载方式全选Decompress On Load，结果内存炸了。音频导入的核心逻辑是区分短音效和长音乐。

短音效（UI点击、射击、脚步）适合用Decompress On Load直接解压到内存，播放零延迟；长音乐和对话适合用Compressed In Memory或Streaming，避免一次性占大量内存。在脚本里我基本按这个原则设置：

private void OnPreprocessAudio() { AudioImporter importer = (AudioImporter)assetImporter; if (assetPath.Contains("BGM") || assetPath.Contains("Music") || assetPath.Contains("音乐")) { importer.loadType = AudioClipLoadType.Streaming; importer.compressionFormat = AudioCompressionFormat.Vorbis; importer.quality = 0.65f; } else { importer.loadType = AudioClipLoadType.DecompressOnLoad; importer.compressionFormat = AudioCompressionFormat.PCM; importer.quality = 1.0f; } importer.preloadAudioData = true; importer.ambisonic = false; }

PCM格式完全不压缩，文件会变大，但换来的是播放性能上的确定性。你不想在战斗场景里因为一个音效的解码卡顿导致掉帧。两条经验：

• 手机项目（Android/iOS）对音频格式要求跟PC不同，AudioImporterOverrideSampleRateSettings和平台专属设置要用importer.SetOverrideSampleSettings处理，否则不同平台跑出来音质不一样。
• preloadAudioData默认是true，但如果你用了Streaming加载类型，预加载数据就没意义了，反而增加启动时间。所以loadType = Streaming时preloadAudioData最好关掉。

3.5 自定义导入配置：用ScriptableObject做规则中心

随着策略规则越来越多，直接把规则硬编码在Processor里会越来越难维护。工程中期我一般会引入一个ScriptableObject作为配置中心，把可调参数抽出来。比如纹理最大尺寸、压缩格式、UI的PPU（Pixels Per Unit）、模型的动画类型开关，这些都放到配置里，由技术负责人统一维护，不用改代码就能调整。

[CreateAssetMenu(menuName = "Pipeline/ImportSettingsConfig")] public class ImportSettingsConfig : ScriptableObject { public int uiMaxTextureSize = 2048; public int characterMaxTextureSize = 1024; public float uiPixelsPerUnit = 100f; [Header("音频")] public AudioClipLoadType bgmLoadType = AudioClipLoadType.Streaming; public AudioClipLoadType sfxLoadType = AudioClipLoadType.DecompressOnLoad; }

然后把ImportSettingsConfig放在Resources或者通过AssetDatabase.LoadAssetAtPath加载。注意这里有个坑：如果你把配置放在Resources目录下，打包时会被打进去，那是纯浪费包体；如果放在Editor目录下，运行时访问不到。所以最合适的做法放在项目任意非Resources目录，通过AssetDatabase加载，并且加上[NoCreateAssetMenu]属性避免误创建——其实CreateAssetMenu本身就会让右键菜单多一个选项，你保留也行，只要你知道它只服务于编辑器。

4. 跨平台处理与平台差异化配置

Unity项目真正上线的时候，目标平台几乎不可能只有一个。手游团队至少要同时面对Android和iOS，PC项目可能还要出Mac和Linux版本。不同平台的纹理压缩格式完全不同，这一块如果不处理好，要么包体爆炸，要么运行卡顿。

4.1 纹理的平台差异化设置

Unity的纹理导入设置天然支持平台差异化。TextureImporter里有platformSettings属性，你可以对每个平台单独设置maxTextureSize和format。我在脚本里是这么做的：

private void ApplyPlatformSettings(TextureImporter importer) { // 先设置默认/独立平台格式 var defaultSettings = importer.GetDefaultPlatformTextureSettings(); defaultSettings.textureCompression = TextureImporterCompression.Compressed; defaultSettings.compressionQuality = 50; // Android // var androidSettings = importer.GetPlatformTextureSettings("Android"); androidSettings.overridden = true; androidSettings.format = TextureImporterFormat.ASTC_6x6; androidSettings.maxTextureSize = 1024; // iOS var iosSettings = importer.GetPlatformTextureSettings("iPhone"); iosSettings.overridden = true; iosSettings.format = TextureImporterFormat.ASTC_6x6; iosSettings.maxTextureSize = 1024; if (importer.textureType == TextureImporterType.Sprite) { androidSettings.compressionQuality = 50; iosSettings.compressionQuality = 50; } importer.SetPlatformTextureSettings(androidSettings); importer.SetPlatformTextureSettings(iosSettings); }

需要注意的是，GetPlatformTextureSettings拿到的是原有设置对象，直接用成员变量方式修改它，再SetPlatformTextureSettings一次性写回。如果你在循环里反复Get/Set，开销会成倍增加，因为每次Set都会触发一次序列化。

格式选择这里，Android和iOS的差异在ASTC成为两平台主流格式后其实简化了很多。老项目还在用ETC2和PVRTC分平台处理，现在的手机基本都支持ASTC，统一用ASTC就能兼顾性能与内存。ASTC_6x6是相对平衡的选项，质量过得去、体积可控。如果你的项目对画质有硬指标，可以改为ASTC_5x5或者ASTC_4x4，代价是包体和内存增大，这个权衡要看项目情况。

4.2 平台差异化后如何自查

平台差异化的设置有一个高效的自查手段：切到对应平台，选中资源，看Inspector的Preview和Importer设置是否跟预期一致。脚本处理的资源数量太大时，肉眼检查不现实，我建议在Processor里加一段校验日志输出，只在UnityEditor的Console里输出被修改过的资源摘要。

private void LogImportSummary(string assetPath, string type, params (string, object)[] settings) { if (!Application.isBatchMode) return; var sb = new System.Text.StringBuilder(); sb.Append($"[Import] {type} | {assetPath}"); foreach (var pair in settings) sb.Append($" | {pair.Item1}: {pair.Item2}"); Debug.Log(sb.ToString()); }

这个日志在CI（持续集成）环境下特别有用。你可以跑一个batch mode下的ReimportAll，把日志抓到流水线里做diff，发现哪个资源的设置被人为改歪了，一眼就能看出来。

5. 实战：一个完整导入流程的编码与调试

5.1 从零开始写一个带完整规则的Processor

我们以角色模型文件夹为例，把前面所有模块串起来，写一个带完整规则的Processor。假设项目目录结构是：

Assets/Art/Characters/Player/Player.fbx Assets/Art/Characters/Player/Textures/Player_D.png Assets/Art/Characters/Player/Textures/Player_N.png Assets/Art/Characters/Player/Animations/Player@Idle.fbx Assets/Art/Characters/Player/Animations/Player@Run.fbx

完整Processor长这样：

#if UNITY_EDITOR using System.IO; using UnityEditor; using UnityEngine; public class CharacterAssetProcessor : AssetPostprocessor { // ---------- 纹理 ---------- private void OnPreprocessTexture() { if (!assetPath.Contains("/Characters/")) return; TextureImporter importer = (TextureImporter)assetImporter; // 判断是法线贴图 if (assetPath.Contains("_N") || assetPath.Contains("_Normal")) { importer.textureType = TextureImporterType.NormalMap; importer.textureCompression = TextureImporterCompression.Compressed; importer.maxTextureSize = 1024; return; } importer.textureType = TextureImporterType.Default; importer.mipmapEnabled = true; importer.fadeOut = true; importer.wrapMode = TextureWrapMode.Repeat; importer.filterMode = FilterMode.Trilinear; importer.textureCompression = TextureImporterCompression.Compressed; importer.maxTextureSize = 1024; // 平台差异化压缩格式 var android = importer.GetPlatformTextureSettings("Android"); android.overridden = true; android.format = TextureImporterFormat.ASTC_6x6; android.maxTextureSize = 1024; importer.SetPlatformTextureSettings(android); } // ---------- 模型 ---------- private void OnPreprocessModel() { if (!assetPath.Contains("/Characters/")) return; ModelImporter importer = (ModelImporter)assetImporter; importer.importBlendShapes = true; importer.importVisibility = true; // 纯动画文件 if (assetPath.Contains("@")) { importer.importAnimation = true; importer.importMesh = false; importer.materialLocation = ModelImporterMaterialLocation.External; } else { importer.importAnimation = false; importer.materialLocation = ModelImporterMaterialLocation.External; importer.materialSearch = ModelImporterMaterialSearch.RecursiveUp; } // 如果目录带Humanoid关键字，设置人形Avatar if (assetPath.Contains("Humanoid")) { importer.animationType = ModelImporterAnimationType.Human; importer.avatarSetup = ModelImporterAvatarSetup.CreateFromThisModel; } else { importer.animationType = ModelImporterAnimationType.Generic; } } // ---------- 音频 ---------- private void OnPreprocessAudio() { if (assetPath.Contains("/Audio/SFX/")) { AudioImporter importer = (AudioImporter)assetImporter; importer.loadType = AudioClipLoadType.DecompressOnLoad; importer.compressionFormat = AudioCompressionFormat.PCM; importer.preloadAudioData = true; } else if (assetPath.Contains("/Audio/BGM/")) { AudioImporter importer = (AudioImporter)assetImporter; importer.loadType = AudioClipLoadType.Streaming; importer.compressionFormat = AudioCompressionFormat.Vorbis; importer.preloadAudioData = false; } } // ---------- 导入完成后统一校验 ---------- private void OnPostprocessAllAssets(string[] importedAssets, string[] deletedAssets, string[] movedAssets, string[] movedFromAssetPaths) { foreach (string path in importedAssets) { if (path.EndsWith(".psd") || path.EndsWith(".psb")) { Debug.LogWarning($"[Import][PSD] 建议将PSD导出为PNG后导入: {path}"); } if (path.EndsWith(".fbx") && path.Contains(" @")) { Debug.LogWarning($"[Import][命名] FBX文件名含空格，建议使用下划线替换: {path}"); } } } } #endif

这个Processor覆盖了常见的三种资源类型，加上导入后的整体校验。实际项目里你可以在这个基础上继续扩展，比如增加Shader的导入校验、预制体的命名规则检查等。

5.2 如何调试导入脚本

导入脚本最常见的问题是“回调没有被触发”和“改了没生效”。这里分享几个调试方法：

第一，在Processor构造函数中加输出。AssetPostprocessor对象被创建时加一行打印，可以确认Unity是否识别了你的脚本。如果你加了断点但没进构造函数，多半是脚本没放在Editor目录下，或者类名和文件名不一致。

第二，强制Reimport验证逻辑。假设你改了导入规则，想验证是否生效，手动把资源删掉再重新放回去，或者右键资源选择Reimport。注意Reimport有两种，Reimport Asset只更新该资源，Reimport All会全量重导，全量重导耗时很长，建议只针对单个资源做验证。

第三，利用AssetDatabase的ImportAsset精确验证。写一个菜单项，点击后自动修改一份测试资源的设置，然后重新导入并打印结果：

[MenuItem("Tools/Reimport And Validate")] public static void ReimportAndValidate() { string path = "Assets/Art/Characters/Test_Player.fbx"; AssetDatabase.ImportAsset(path, ImportAssetOptions.ForceUpdate); var importer = AssetImporter.GetAtPath(path) as ModelImporter; Debug.Log($"AnimationType: {importer.animationType}"); Debug.Log($"BlendShapes: {importer.importBlendShapes}"); }

这条路子的好处是可以精确复现问题，比随机看Console靠谱得多。

5.3 批量清洗旧资源

项目中期你可能会遇到一个非常讨厌的情况：导入脚本是新写的，但项目里已经存在大量导入时不规范的老资源了。比如几千张贴图，当年导入时全部是用默认设置，现在有了规则脚本，新导的图都规范了，老图却还是老样子。

解决办法是写一个“资产清洗”工具。利用AssetDatabase.FindAssets找到所有目标类型的资源，然后逐个设置Importer并重新导入。我自己项目里的做法是这样的：

[MenuItem("Tools/Import/Cleanup All Textures")] public static void CleanupAllTextures() { string[] guids = AssetDatabase.FindAssets("t:Texture", new[] { "Assets/Art" }); int count = 0; foreach (string guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); AssetDatabase.ImportAsset(path, ImportAssetOptions.ForceUpdate); count++; } AssetDatabase.SaveAssets(); Debug.Log($"清洗完成，共处理 {count} 个纹理资源"); }

注意这个操作如果资源量极大，耗时可能很长，建议先在小范围目录里测试再全量跑。另一个点是FindAssets("t:Texture")会把Sprite和Normal map也包含进来，需要根据路径再过滤。我的经验是先挑出10个典型资源配置一下，确认符合预期后再全量执行。

6. 团队协作中的导入脚本维护

6.1 不要让导入脚本变成“死规则”

技术负责人最容易犯的错误，是写了一套规则脚本之后，丢给团队用，自己撒手不管。项目跑几个月后，美术说“为什么这个贴图压缩这么糊”，策划说“为什么模型导入得这么慢”，各种抱怨都来了，但没人敢改脚本，因为怕改了影响一堆资源。

我的经验是，导入规则脚本本质上是一个活文档。它需要跟项目一起迭代，美术提了新的通道需求、策划改了Texture Size上限，脚本必须同步变更。因此我建议：

1. 每个迭代版本给导入脚本留出专门的Review时间，和美术一起过一遍规则是否合理。
2. 导入规则变更时，用版本管理工具跑一次规则变更Diff，看看有多少资源会被重新导入。如果数量巨大，必须分批执行，避免把美术的电脑卡死。
3. 重要规则的变更一定要做回归测试，准备一套基准资源（包含各类型纹理、模型、音频），跑完之后截图对比渲染结果。

6.2 编辑器的批量模式与CI集成

如果你的团队已经上了自动化构建流程，那AssetPostprocessor在批处理模式下依然有效，这是Unity极其好用的一面。你完全可以写一个批处理命令：

Unity.exe -batchmode -projectPath 项目路径 -executeMethod Tools.Import.RefreshAll -quit

然后在CI里对每次合并到主干的资源变更跑一次全量Reimport，如果某个资源的导入设置不符合脚本规则，CI会直接报错失败。这样就把“规则执行”从个人自觉提升到了工程流程层面。

不过要注意若干细节：

• 批处理模式下输出日志用Debug.Log依然有效，但中文路径可能乱码，建议日志用英文。
• 批处理模式某些编辑器API（比如弹出对话框）会被忽略，所以脚本里所有交互都要用参数或配置文件控制，不要在OnPreprocess*里调用EditorUtility.DisplayDialog，会卡死批处理。
• CI机器的平台可能与开发机不同，如果CI跑的是Linux或Mac，但Unity Shader、纹理压缩等在Windows上可能有差异，务必确保CI环境和目标构建平台一致，至少纹理压缩设置要统一。

6.3 版本控制注意：Meta文件也属于工程资产

Unity的.meta文件记录了资源的GUID和导入设置，是项目工程里必须纳入版本控制的文件。但有些团队图省事，把.meta加进了.gitignore，这会让导入脚本的规则在别人电脑上重新生成meta时产生大量漂移，而且很可能会导致资源引用中断。我的建议是：

• .meta必须提交到Git/SVN，除非你用的是Unity Collaborate或者Perforce这类Unity原生支持的工具。
• 版本控制里，如果Merge冲突发生在.meta文件，千万不要随意接受某一边，因为另一边可能改了GUID。正确做法是让最近的修改方重新执行一次Reimport，再提交。
• 在.gitattributes里设置*.meta merge=unityyamlmerge，使用Unity自带的YAML合并工具解决冲突，比Git默认的逐行合并要聪明很多。

6.4 导入脚本与LFS（Large File Storage）的配合

大型Unity项目通常都要接Git LFS来处理FBX、PSD、音频这些大文件。导入脚本在LFS环境里多了一个隐患：LFS使用smudge/clean过滤，资源文件在本地磁盘上是“指针文件”，AssetDatabase访问时发现文件尺寸不对就去下载，下载过程中触发导入，可能产生竞态问题。

具体来说，如果你在OnPostprocessAllAssets里又去访问其他还没有下载完的资源配置，就可能拿到错误数据。解决方案有两个：

1. 在CI阶段先执行git lfs pull，确保所有LFS文件拉取到本地后再跑Reimport。
2. 在导入脚本里对可能触发下载的资源做保护判断，比如检查文件是否真的存在且大小不为0：

if (File.Exists(path) && new FileInfo(path).Length > 0) { // 执行处理 }

这两个方案按需混用，基本能规避LFS环境下的导入坑。

7. 常见问题与排查技巧实录

7.1 回调不触发的几大原因

我经常看到论坛上有帖子说“我写了AssetPostprocessor但OnPreprocessTexture没反应”，排查顺序基本是这样：

1. 脚本是否在Editor目录下。严格来说Editor和Editor/子目录都行，但如果你把脚本放在Scripts目录下只加了#if UNITY_EDITOR，那是不行的，因为AssetPostprocessor类本身位于UnityEditor命名空间，普通程序集编译时根本找不到这个类。
2. 文件名和类名是否匹配。C#要求文件名跟公共类名一致，不一致时Unity会编译通过但编辑器行为怪异。
3. 方法签名是否正确。OnPreprocessTexture必须是private void，不能带参数，不能是static。一旦方法签名不对，Unity的反射调用直接忽略。
4. 资源是否真的触发了导入。如果你把AssetPostprocessor写好了，但资源之前已经被导入过，且meta没变化，Unity不会重新导入，所以就不会触发回调。右键资源Reimport可以验证。

7.2 改了Importer设置但没生效

这个问题的根源通常是：没有重新导入资源。Importer设置是你修改了，但资源已经在缓存里，没有强制的AssetDatabase.ImportAsset调用就不会刷新。一个比较隐蔽的场景是在OnPostprocessAllAssets里改Importer设置，这样改完之后当前这个资源的导入已经结束了，你改的设置要等下一次导入才生效。

解决办法是：修改导入设置之后，如果需要立即生效，手动加一次强制导入：

AssetDatabase.ImportAsset(path, ImportAssetOptions.ForceUpdate);

注意ForceUpdate会重新解析文件，如果资源量很大，不要反复调用，否则性能会很差。

7.3 导入脚本的性能问题

资源导入是一个高频率操作，例如美术复制粘贴一百张图片，Unity会逐个触发OnPreprocessTexture。如果你在每个回调里都做大量字符串正则、磁盘IO、反射调用，那导入过程会卡到爆。

性能优化核心是提前返回。在进入具体逻辑之前，先用最轻量的条件过滤掉不匹配的资源。例如：

private void OnPreprocessTexture() { if (!assetPath.StartsWith("Assets/Art/UI/")) return; // 剩下的才是需要处理的UI资源 }

这种写法比先执行一长串逻辑再内部判断要高效得多，因为Unity字符串操作的开销比你想象的大。

另外，在脚本里尽量避免每帧或每资源去使用AssetDatabase.LoadAssetAtPath，尤其是加载大资源，这会拖慢导入速度。可以用缓存方式，把路径和配置结果缓存进Dictionary，减少重复加载。

7.4 资源导入与Shader的关系

纹理和模型的导入设置跟Shader渲染效果直接挂钩。如果导入脚本设置不对，最终渲染往往会出现难以定位的图片问题。比如法线贴图没设为NormalMap，灯光下模型表面会显得异常亮或“凹凸感丢失”；比如UI的Sprite还开着Mipmap，缩放后出现模糊或闪烁；比如WrapMode不是Repeat，地形纹理平铺会接缝异常。

在排查这类渲染问题时，优先检查导入设置往往比改Shader代码更高效。我给团队定的排查顺序是：先看资源的Importer设置是否符合规范，再看材质球引用的贴图是否有问题，最后才动Shader。

8. 我的实操经验总结

最后聊聊我自己在项目管理中实际摸索出来的几条经验，很多是从教训里换来的。

8.1 规则别一开始就写得太“死”

我在新项目的第一个版本里写过一刀切的规则，比如“所有纹理不得大于1024”。结果美术做UI大图需要2048，做地形远景需要4096，我直接给压碎了，画面质量肉眼可见下降。后来我改成按目录分类，UI归UI、场景归场景，才解决了问题。

规则的本质是分类管理，不是一刀切。你在写规则脚本之前，先花两周时间盘点项目的资源类型，按目录、按用途、按平台把资源分成几类，然后每类给一套规则。这样写出来的脚本才能覆盖真实需求，不会让美术到处骂你。

8.2 导入脚本也要写测试

很多人写业务代码会写单元测试，但写编辑器工具时基本不写测试。导入脚本这种影响面极大的代码，恰恰最需要测试。我不要求你上Unity Test Framework，但至少要维护一个测试资源集：

• 一张UI图、一张场景贴图、一张法线图、一张带透明通道的图
• 一个角色模型、一个纯动画文件、一个带BlendShape的模型
• 一个短音效、一个长音乐

每次改导入脚本，把测试资源Reimport一遍，肉眼检查预览窗口或者用代码断言关键参数。这个习惯能省掉你后期大量排雷时间。

8.3 用日志替代口头传达

团队里如果导入规则变了，不要只在微信群里说，要把变更记录写进脚本的注释里，并且在OnPostprocessAllAssets里对受影响目录输出警告。比如规则变更后第一次Reimport，输出“这批资源不符合新规则，已自动修复”，美术看到日志就知道发生了什么。日志写清楚，比口头解释一百遍都有用。

8.4 导入脚本的边界：不要碰不该碰的资源

最后一条比较“老油条”的经验：导入脚本是给团队把最后一道关的，但它不是万能的，更不是用来和美术较劲的。有些资源路径非常特殊，比如某些插件自带的示例资源、测试专用的临时图，你如果也去强制套规则，反而会把插件搞坏。所以规则脚本里一定要留一个白名单机制，让特定目录的资源跳过规则处理。

private bool IsIgnoredPath(string path) { return path.Contains("/ThirdParty/") || path.Contains("/Plugins/") || path.Contains("/Editor Default Resources/"); }

有了白名单，规则脚本才更可靠。毕竟，让该规范的规范，让该自由的自由，才是一个工程化的导入系统该有的样子。你在实际项目里遇到的新情况永远比预想的多，保持脚本可维护、规则可调整、日志可追踪，这才是资源导入自动化的长久之道。