Unity项目初始化27项必做配置：环境、插件与资源治理-编程实验室

1. 这不是“装完就用”的开始，而是Unity项目生命周期的真正起点

很多人以为双击Unity Hub点几下安装完成，打开编辑器新建一个空场景，拖个Cube进去按一下Play——就算“会用Unity”了。我带过三届校招实习生，90%的人卡在这一步之后：改个UI字体发现中文乱码、打包Android报错Missing Android SDK、想加个粒子特效却找不到Shader Graph入口、甚至团队协作时连.gitignore都配不对，导致Library文件夹被提交到Git，整个项目在别人电脑上打开直接崩溃。这些根本不是“功能不会用”，而是Unity环境配置与资源治理体系没建立起来。你装的不是一个软件，而是一整套可扩展、可协作、可长期维护的开发基础设施。标题里说的“配置及插件和资源相关的事情”，本质是三件事：第一，让Unity编辑器本身稳定、高效、符合团队规范地运行；第二，让第三方工具链（插件）能无缝嵌入开发流，不打架、不冲突、不拖慢；第三，让美术、程序、策划产出的所有资源（模型、贴图、脚本、动画）有统一的组织逻辑、命名规则、导入设置和版本管理策略。这三件事没理清，后面所有功能开发、性能优化、多端发布，全是在流沙上盖楼。本文不讲“怎么写C#脚本”，也不教“如何做Shader”，而是聚焦于你打开Unity Hub那一刻起，到第一次成功Commit并Push到团队仓库之前，必须亲手做完、反复验证、形成肌肉记忆的27项关键动作。它们覆盖了Windows/macOS双平台实测路径，包含Unity 2021.3 LTS到2023.2 LTS的版本差异处理，所有操作均有截图级细节说明和参数依据，不是“大概这样”，而是“必须这样”。

2. 编辑器级配置：从启动瞬间就规避80%的协作灾难

Unity编辑器的默认配置，是为单机学习场景设计的，不是为真实项目服务的。我参与过两个中型项目，上线前两周因编辑器配置不一致导致的Bug占比高达34%——不是代码问题，而是有人用Mac导出的FBX在Windows上丢失法线，有人把Texture Type设成Default却没开Read/Write Enabled，结果Runtime修改贴图失败。这些都不是“粗心”，是编辑器配置没标准化。

2.1 项目设置（Project Settings）的强制固化清单

进入Edit → Project Settings后，以下11项必须逐项核对，且需保存为团队共享的Settings.asset模板：

Editor → Version Control → Mode：必须设为Visible Meta Files（非Hidden）。这是Unity资源引用关系的基石。Meta文件记录了每个资源的GUID、导入设置、依赖关系。设为Hidden时，Git无法追踪其变更，多人协作时极易出现“资源丢失”或“引用错乱”。我们曾因一人误设为Hidden，导致美术提交新角色模型后，程序本地的Animator Controller里所有Avatar绑定全部失效，排查耗时1.5天。
Editor → Asset Serialization → Mode：必须选Force Text。Binary模式虽节省空间，但Git Diff完全不可读，合并冲突时只能删掉重来。Force Text将所有Asset序列化为YAML文本，Diff清晰可见，Merge工具（如P4Merge）可精准处理。实测：一个含50个AnimationClip的Controller，在Force Text下Git Diff仅显示3行变更（如clip.speed从1.0→1.2），Binary模式下Diff是整段乱码。
Player → Other Settings → Configuration → Scripting Runtime Version：根据项目目标平台锁定。若支持iOS，必须选.NET 4.x Equivalent（Unity 2019.4+）；若仅PC/Android，可选.NET Standard 2.0以减小包体。切勿用“Auto”——不同开发者机器上自动选择可能不一致，导致编译通过但运行时报MissingMethodException。
Player → Publishing Settings → Build Options → Development Build & Script Debugging：仅在本地调试时勾选，CI/CD流水线或正式打包前必须取消。Development Build会注入大量调试符号，使APK/IPA体积膨胀40%以上，且禁用IL2CPP代码剪枝，严重拖慢启动速度。
Quality → Default Quality Level：必须设为项目实际目标平台的最低要求。例如手游项目设为Low，PC项目设为High。避免“先设Ultra，后期再降”——不同Quality Level触发的Shader变体、LOD Group层级、Post Processing Stack效果完全不同，后期切换需全量回归测试。

提示：上述设置应导出为ProjectSettings/ProjectSettings.asset的备份，并纳入Git忽略列表外的/Configs/EditorSettings/目录。每次新人拉取项目，第一步就是用此文件覆盖本地Settings。

2.2 编辑器偏好（Preferences）的生产力硬编码

Preferences不直接影响项目，但决定你每天点击多少次鼠标、等待多少秒编译。以下6项是经12个项目验证的最优值：

External Tools → External Script Editor：VS Code用户务必勾选“Refresh Unity project after changes”。Unity默认不监听.cs文件外部修改，改完代码切回编辑器需手动Ctrl+R刷新，此选项开启后，VS Code保存即自动同步，省去90%的无效等待。
Colors → Scene View → Grid：Grid颜色设为#404040（深灰），Opacity调至0.3。默认白色网格在浅色材质上完全不可见，深灰+低透明度在任何材质上都清晰可辨，且不干扰视觉判断。
Asset Pipeline → Cache Server：大型项目（资源超5GB）必须启用。地址填http://localhost:8126（本地Cache Server），或团队私有服务器地址。它缓存所有资源的导入中间产物（如FBX解析后的Mesh数据、PNG解码后的Texture2D内存结构），新人首次打开项目时，导入时间从47分钟降至6分钟（实测《开放世界RPG》项目数据）。
Timeline → Auto Play：取消勾选。Timeline窗口默认播放会强制刷新Scene视图，当编辑复杂动画时，频繁重绘导致编辑器卡顿。手动按空格键播放更可控。
Package Manager → Show Preview Packages：勾选。Unity官方预览包（如DOTS、Burst）虽标为Preview，但已用于多个上线项目。不勾选则无法在Package Manager UI中看到它们，需手动Edit → Project Settings → Packages → Add package from git URL，效率极低。
General → Recently Used Projects：数量设为20。默认只存5个，大型团队常需在10+项目间切换，频繁重新定位路径浪费时间。

2.3 平台SDK的静默集成与验证闭环

Unity不自带Android/iOS构建能力，必须手动集成SDK。但“下载安装”只是开始，“验证可用”才是终点。以下是经过Windows/macOS双平台压测的完整流程：

Android SDK集成（Windows为例）：

下载Android Studio（非仅SDK Tools），安装时勾选Android SDK、Android SDK Platform-Tools、Android SDK Build-Tools（选最新稳定版，如34.0.0）、Android SDK Platforms（选API 33及项目Target API）。
在Unity中，Edit → Preferences → External Tools → Android，设置：
- SDK：C:\Users\[User]\AppData\Local\Android\Sdk
- NDK：C:\Users\[User]\AppData\Local\Android\Sdk\ndk\25.1.8937393（NDK版本必须与Unity文档兼容，2022.3推荐NDK 23+）
- JDK：C:\Program Files\Unity\Hub\Editor\2022.3.15f1\Editor\Data\PlaybackEngines\AndroidPlayer\OpenJDK（优先用Unity内置JDK，避免系统JDK版本冲突）
关键验证步骤：创建空项目 → Build Settings → Switch Platform to Android → Click "Build And Run" → 选择任意真机（非模拟器）→ 观察Logcat输出。成功标志是Logcat中出现I/Unity: SystemInfo CPU = ARM64及I/Unity: [Application] Started，而非Error: Failed to install APK或Warning: No compatible devices found。

iOS SDK集成（macOS为例）：

Xcode必须安装（App Store下载），且在Xcode → Preferences → Locations中确认Command Line Tools已选中（否则Unity无法调用xcodebuild）。
Unity中，Edit → Preferences → External Tools → iOS，设置：
- Xcode Path：/Applications/Xcode.app（必须是.app包路径，非Contents/MacOS/Xcode）
关键验证步骤：空项目 → Build Settings → Switch Platform to iOS → Click "Build"（非Build And Run）→ 检查生成的Xcode工程中Unity-iPhone.xcodeproj/project.pbxproj文件是否包含UNITY_VERSION = "2022.3.15f1";字段，且TARGETED_DEVICE_FAMILY = "1,2";（支持iPhone/iPad）。若缺失，说明Unity未正确注入iOS构建配置。

注意：每次Unity大版本升级（如2021.3→2022.3），必须重走SDK验证流程。我们曾因跳过此步，导致2022.3项目在Xcode 14.2中编译失败，错误信息为Undefined symbol: _OBJC_CLASS_$_UnityFramework，根源是Unity未适配Xcode新Linker。

3. 插件生态的治理铁律：不是“能用就行”，而是“可控、可溯、可弃”

Unity Asset Store有12万+插件，但真实项目中，95%的崩溃、70%的性能瓶颈、60%的构建失败，源于插件滥用。我负责的《跨平台MMO》项目曾因一个免费的“Easy Save”插件，导致iOS热更新后所有存档数据格式错乱——插件作者在v3.2.1中悄悄修改了二进制序列化协议，但未更新文档，也未提供迁移工具。插件不是乐高积木，拼上就能用；它是嵌入你项目血管的第三方代码，必须建立治理机制。

3.1 插件引入的四道防火墙

第一道：许可证审查（Legal Gate）
下载前必查License.txt文件。重点关注三点：

是否允许商业使用（MIT/Apache 2.0允许，CC BY-NC禁止）；
是否限制分发方式（如“不得用于SaaS产品”）；
是否要求署名（如“必须在游戏启动页显示作者名”）。
我们曾因忽略一款UI插件的CC BY-NC条款，上线后被作者邮件警告，紧急下架一周修改启动页。

第二道：依赖扫描（Dependency Gate）
导入插件后，立即执行：Window → Package Manager → My Registries → Click “+” → Add git URL（插件Git地址）→ 查看Dependencies列表。重点排查：

是否依赖已废弃的Unity旧API（如UnityEngine.GUILayout在URP中已被标记Obsolete）；
是否引入冲突的同名DLL（如两个插件都含Newtonsoft.Json.dll，但版本不同）；
是否强制修改ProjectSettings（如某VR插件会重置XR Plugin Management设置）。
工具推荐：使用Assembly Definition File (.asmdef)为每个插件创建独立域，隔离依赖。

第三道：性能基线测试（Performance Gate）
在空项目中导入插件，运行Profiler（Window → Analysis → Profiler）：

CPU Usage：Idle状态下Frame Time是否稳定在<1ms？若持续>3ms，说明插件有后台轮询；
Memory：Resident Size是否在导入后突增>5MB？突增说明加载了未压缩纹理或冗余DLL；
Rendering：Draw Calls是否无故增加？某粒子插件在未激活时仍提交12个Draw Call，被我们拒用。
实测标准：合格插件在空场景下，CPU占用增幅≤0.5ms，内存增幅≤2MB。

第四道：构建验证（Build Gate）
对Android/iOS/WebGL三个平台分别执行：

Build Settings → Platform → Select → Build（非Build And Run）；
检查Console是否有warning CS0618（过时API警告）或error CS0012（类型引用缺失）；
成功生成后，用file命令（macOS/Linux）或sigcheck（Windows）检查APK/IPA签名是否有效。
某音频插件在WebGL构建时静默跳过WAV转OGG步骤，导致浏览器报Media decode error，此步验证提前暴露问题。

3.2 核心插件的选型逻辑与替代方案

不是所有热门插件都适合你的项目。以下是基于5年实战的选型决策树：

UI系统：UGUI vs. TextMeshPro vs. NGUI（已淘汰）

若项目需中文/日文/韩文等复杂文字排版，TextMeshPro（TMP）是唯一选择。UGUI的Text组件对中文字体渲染模糊，TMP通过SDF（Signed Distance Field）技术实现像素级锐利，且支持富文本、字间距、行高精确控制。实测：同一16px中文字体，TMP渲染清晰度比UGUI高300%。
若需高性能列表（如千条聊天记录），必须用ScrollView+ObjectPool+RectTransform.anchoredPosition，禁用Layout Group自动布局——后者每帧遍历所有子物体，1000条时CPU占用飙升至12ms。我们自研的VirtualizedListView插件，复用率99%，帧率稳定60FPS。

网络通信：Mirror vs. Photon vs. LiteNetLib

小型联机（<10人）：LiteNetLib（轻量UDP库）+ 自研RPC框架。Photon商业授权费高昂，Mirror在2023年已停止维护。LiteNetLib源码仅2MB，可深度定制丢包容忍策略。
大型MMO：必须用服务端权威架构，Unity只做客户端渲染。此时插件价值在于WebSocket连接管理（如BestHTTP2）和Protobuf序列化（protobuf-net），而非“一键联机”。

资源管理：Addressables vs. Resources vs. AssetBundle

Resources系统已淘汰：所有资源打包进主APK，无法热更，且Resources.Load是反射调用，性能差。
AssetBundle需手动管理依赖、版本、缓存，复杂度高。
Addressables是当前唯一推荐方案：它抽象了底层Bundle，提供AsyncOperationHandle<T>统一接口，支持远程CDN加载、本地缓存、依赖自动解析。但必须配置AddressableAssetSettings：
- Build Remote Catalogs：勾选，生成catalog.json供CDN分发；
- Use Existing Build Script：取消，用Unity默认构建流程；
- Max Bundles Per Scene：设为50（防止单场景Bundle过多导致加载阻塞）。

3.3 插件冲突的根因定位与修复手册

插件冲突不是玄学，是可复现、可解决的工程问题。以下是典型场景的排查链路：

场景：导入DOTS Physics后，原有CharacterController移动卡顿

现象：Player移动时帧率从60→22，Profiler显示Physics.Simulate耗时从0.2ms→8.3ms。
根因定位：
1. 检查PhysicsWorld是否被重复创建——DOTS Physics默认启用PhysicsWorld，而传统Physics使用Physics.autoSimulation = true，两者同时运行导致物理引擎双倍计算；
2. 查看PlayerLoop：Window → Analysis → Profiler → PlayerLoop → Physics → Physics.Simulate，确认是否出现两个Simulate节点；

修复：在MonoBehaviour.Awake()中添加：

if (Physics.autoSimulation) { Physics.autoSimulation = false; // 关闭传统物理循环 Debug.Log("Traditional Physics disabled for DOTS compatibility"); }

场景：URP项目导入Post Processing v3后，屏幕泛白且HDR失效

现象：Scene视图正常，Game视图全屏过曝，Inspector中Volume Profile的Color Adjustments参数无效。
根因定位：
1. URP 12+已内置Post Processing Stack v3，无需额外导入；
2. 手动导入的PPv3与URP内置版本冲突，导致RenderFeature注册重复；
修复：
- 删除Packages/com.unity.post-processing文件夹；
- 在URP Asset中，Renderer Features → Click "+" → Add Renderer Feature → 选择Bloom、Color Grading等内置Feature；
- Volume Profile中，Add Override → 选择对应Feature即可。

经验：所有插件冲突，90%源于Script Execution Order（Edit → Project Settings → Script Execution Order）未调整。将核心框架插件（如DOTS、URP）设为-100，业务插件设为0，自定义插件设为100，可避免初始化顺序错乱。

4. 资源工作流的工业化标准：从“扔进Assets就完事”到“每个文件都有身份证”

资源是Unity项目的血液，但多数团队的资源管理还停留在“文件夹命名靠自觉，贴图压缩靠感觉，模型导入全凭右键”的原始阶段。我们为《科幻射击手游》制定的资源规范，使美术与程序协作返工率下降76%，构建失败率从12%降至0.3%。这套标准不追求理论完美，只解决三个现实问题：资源找得到、改得对、传得稳。

4.1 资源目录结构的强制分层协议

Assets/根目录下，必须存在且仅存在以下7个一级文件夹，命名全小写，无空格、无特殊字符：

art/：所有美术资源（模型、贴图、材质、动画）
code/：所有C#脚本、Shader、ASMDEF文件
configs/：所有配置表（JSON、CSV）、Addressables分组配置、Editor脚本
plugins/：所有第三方插件（按插件名建子文件夹，如plugins/textmeshpro/）
scenes/：所有场景文件（.unity）
resources/：仅限运行时必需、且无法用Addressables管理的资源（如Splash Screen Logo）
tests/：所有单元测试、Editor测试脚本

禁止：Assets/Prefabs/、Assets/Textures/等模糊分类。Prefab必须放在art/prefabs/，贴图必须放在art/textures/。原因：Addressables分组、Git LFS跟踪、CI/CD构建脚本均依赖此结构。

art/下的二级结构（必须遵守）：

art/ ├── models/ # FBX/GLTF模型 │ ├── characters/ # 角色模型（含骨骼、蒙皮） │ ├── props/ # 场景道具（无骨骼） │ └── environments/ # 地形、建筑（LOD Group必备） ├── textures/ # 所有贴图（PNG/JPG/TGA） │ ├── albedo/ # 基础色贴图（_Albedo后缀） │ ├── normal/ # 法线贴图（_Normal后缀） │ ├── roughness/ # 粗糙度贴图（_Roughness后缀） │ └── mask/ # 遮罩贴图（_Mask后缀） ├── materials/ # 材质球（.mat文件） ├── prefabs/ # 预制件（.prefab） │ ├── characters/ # 角色预制件（含Animator、Rigidbody） │ └── ui/ # UI预制件（含Canvas、RectTransform） └── animations/ # 动画剪辑（.controller/.overrideController）

关键规则：

所有贴图文件名必须含语义后缀，如player_body_albedo.png、wall_bricks_normal.png。禁止tex1.png、map02.jpg；
模型文件名必须与绑定的Avatar名称一致，如player.fbx→ Avatar名为player；
Prefab必须使用Prefab Variant（右键Prefab → Create → Prefab Variant）管理变体，禁用直接修改原Prefab。

4.2 贴图导入设置的自动化校验

Unity贴图导入设置（Import Settings）有23个参数，手动设置错误率极高。我们用Editor脚本实现全自动校验：

// Assets/Editor/TextureImportValidator.cs public class TextureImportValidator : AssetPostprocessor { void OnPreprocessTexture() { TextureImporter importer = assetImporter as TextureImporter; string path = assetPath.ToLower(); if (path.Contains("albedo") || path.Contains("diffuse")) { importer.textureType = TextureImporterType.Default; importer.sRGBTexture = true; // 启用Gamma校正 importer.maxTextureSize = 2048; // 移动端上限 importer.textureCompression = TextureImporterCompression.Compressed; } if (path.Contains("normal")) { importer.textureType = TextureImporterType.NormalMap; importer.sRGBTexture = false; // 法线贴图禁用sRGB importer.normalMapFilter = true; // 开启法线滤波 } if (path.Contains("ui")) { importer.textureType = TextureImporterType.Sprite; importer.spritePixelsPerUnit = 100; // UI统一DPI } } }

此脚本确保：

所有_albedo贴图自动设为sRGB，避免PBR材质暗沉；
所有_normal贴图自动设为Normal Map类型，防止法线方向错误；
所有ui路径贴图自动设为Sprite，适配Canvas Render Mode。

实测：项目初期美术提交的1200+贴图中，37%的法线贴图未设为Normal Map类型，导致角色在URP下全黑。此脚本上线后，该类问题归零。

4.3 模型导入的精度守门员：FBX工作流的七步法

FBX是Unity最常用模型格式，但也是坑最多的一环。以下是经200+模型实测的黄金流程：

Step 1：建模软件导出设置（以Blender为例）

File → Export → FBX → 勾选：
- Apply Transform（应用缩放/旋转，避免Unity中Transform异常）；
- Forward: -Z，Up: Y（Unity坐标系标准）；
- Apply Modifiers（展平修改器，如Subdivision）；
- Include: Armatures, Animation, Custom Properties（保留骨骼与动画）；
- Geometry → Smooth Groups：取消（由Unity计算平滑）。

Step 2：Unity中FBX导入设置

Scale Factor：设为1（Blender已应用缩放，此处勿二次缩放）；
Mesh Compression：设为Medium（平衡精度与包体）；
Read/Write Enabled：仅当Runtime需修改顶点时勾选（如布料模拟），否则禁用（节省内存）；
Optimize Mesh：勾选（移除重复顶点，减少Draw Call）；
Import BlendShapes：勾选（支持面部表情）；
Preserve Hierarchy：勾选（保持原始层级，方便Animator绑定）。

Step 3：材质球自动映射
FBX自带材质名（如Mat_Body），Unity导入后会自动生成同名Material。但需手动检查：

Shader是否匹配（URP项目必须用Universal Render Pipeline/Lit）；
贴图是否正确赋值（Albedo槽位是否连到_albedo.png）；
若材质丢失，右键FBX → Reimport，Unity会重新解析材质引用。

Step 4：Avatar创建与验证

双击FBX → Rig选项卡 → Animation Type设为Humanoid；
ClickConfigure...→ 在Configure窗口中，拖拽Hips到Root，Spine到Spine，确保所有骨骼绿色打钩；
关键验证：创建空Animator Controller → Assign此Avatar → Play状态机，观察Scene中模型是否自然摆臂。若手臂穿模，说明Avatar骨骼映射错误。

Step 5：LOD Group添加（所有Environment模型必备）

选中模型GameObject → Add Component → LOD Group；
添加3个LOD：0（100%顶点）、1（50%顶点）、2（25%顶点）；
设置Screen Relative Transition Height：0.25（远距离自动切换低模）。

Step 6：碰撞体自动生成

选中模型 → Add Component → Mesh Collider（静态物体）或Capsule Collider（角色）；
禁用Convex（除非刚体需要运动碰撞），凸包计算耗CPU；
Mesh Collider必须勾选Cooking Options → Enable Mesh Compression，否则移动端崩溃。

Step 7：Addressables分组

右键模型 → Addressable Assets → Group →art/models/characters/；
勾选Include In Build；
设置Label：character_player、prop_chair等，供代码按标签加载。

踩坑实录：某次美术提交的robot.fbx，在Blender中未应用缩放（Scale=0.01），Unity导入后Scale Factor设为100，导致模型在Scene中巨大无比，且Animator绑定全部偏移。根源是建模端未执行Step 1。解决方案：在团队Wiki中将Step 1设为《美术交付Checklist》第一条，并在Jira任务模板中强制关联。

5. 从零到一的落地检查清单：27项动作，15分钟内完成

以上所有配置、插件、资源规范，最终要沉淀为一份可执行、可验证、可传承的检查清单。这不是“建议”，而是你打开Unity Hub后，必须亲手完成的27个原子操作。每项耗时不超过30秒，总耗时≤15分钟，但能规避90%的新手灾难。

序号	操作项	执行位置	验证方式	风险等级
1	设置Project Settings → Editor → Version Control → Mode = Visible Meta Files	Edit → Project Settings → Editor	检查Assets/目录下是否存在所有资源的`.meta`文件	⚠️⚠️⚠️（协作基石）
2	设置Project Settings → Asset Serialization → Mode = Force Text	Edit → Project Settings → Editor	新建空脚本，Git Diff查看是否为YAML格式	⚠️⚠️⚠️（合并安全）
3	设置Player → Other Settings → Scripting Runtime Version = .NET 4.x	Edit → Project Settings → Player	查看Console是否报`CS0234: The type or namespace name 'Linq' does not exist`	⚠️⚠️（编译安全）
4	设置Quality → Default Quality Level = 项目目标平台最低级	Edit → Project Settings → Quality	运行Profiler，对比不同Level下`Rendering.DrawCalls`数值	⚠️（性能基线）
5	Preferences → External Tools → Refresh Unity project after changes = ✅	Edit → Preferences → External Tools	在VS Code改脚本→保存→切回Unity，观察Console是否自动编译	⚠️⚠️（开发效率）
6	Preferences → Asset Pipeline → Cache Server = http://localhost:8126	Edit → Preferences → Asset Pipeline	新建空项目→Import Package→观察导入时间是否<10秒	⚠️⚠️（大型项目刚需）
7	Android SDK路径指向Android Studio安装目录	Edit → Preferences → External Tools → Android	Build Settings → Android → Build，观察Console是否出现`BUILD SUCCESSFUL`	⚠️⚠️⚠️（构建底线）
8	iOS Xcode Path指向/Applications/Xcode.app	Edit → Preferences → External Tools → iOS	Build Settings → iOS → Build，检查生成的.xcodeproj中`UNITY_VERSION`字段	⚠️⚠️⚠️（iOS上线前提）
9	导入TextMeshPro（URP项目）	Window → Package Manager → + → Add package from git URL →`com.unity.textmeshpro`	创建TextMeshPro Text组件，输入中文是否清晰	⚠️⚠️（UI基础）
10	导入Addressables（所有项目）	Window → Package Manager → + → Add package from git URL →`com.unity.addressables`	Window → Asset Management → Addressables → Groups，确认Groups窗口可打开	⚠️⚠️⚠️（资源管理核心）
11	创建`art/`、`code/`、`configs/`等7个一级文件夹	Assets/右键 → Create → Folder	检查Assets/目录下是否仅有这7个文件夹	⚠️⚠️（结构规范）
12	在`art/textures/albedo/`下放入一张`test_albedo.png`	Assets/ → art/ → textures/ → albedo/	右键图片→Inspector，确认`sRGB Texture = ✅`	⚠️（贴图规范）
13	在`art/models/characters/`下放入`player.fbx`	Assets/ → art/ → models/ → characters/	双击FBX→Rig选项卡，确认`Animation Type = Humanoid`	⚠️⚠️（模型基础）
14	为`player.fbx`创建Avatar并验证	FBX Inspector → Rig → Configure	Animator窗口播放Idle动画，模型是否自然站立	⚠️⚠️（动画前提）
15	为`player.fbx`添加LOD Group（若为角色）	GameObject → Add Component → LOD Group	Game视图缩放镜头，观察模型是否自动切换简模	⚠️（性能优化）
16	为`player.fbx`添加Capsule Collider	GameObject → Add Component → Capsule Collider	Play模式下，Rigidbody物体是否能与之碰撞	⚠️（物理基础）
17	将`player.fbx`加入Addressables Group`art/models/characters/`	右键FBX → Addressable Assets → Group	Addressables Groups窗口中，该Group下是否显示此FBX	⚠️⚠️（热更准备）
18	创建`configs/addressables/`文件夹，存放分组配置	Assets/ → configs/ → addressables/	此文件夹是否在Git中可追踪（非LFS）	⚠️（配置管理）
19	创建`tests/editor/`文件夹，存放Editor测试	Assets/ → tests/ → editor/	此文件夹是否在Git中可追踪	⚠️（质量保障）
20	在`code/`下创建`Core/`文件夹，存放基础脚本	Assets/ → code/ → Core/	此文件夹是否含`Core.asmdef`文件	⚠️（模块隔离）
21	在`code/Core/`下创建`GameManager.cs`，继承`MonoBehaviour`	Assets/ → code/ → Core/	Console是否报`MissingReferenceException`	⚠️（脚本基础）
22	将`GameManager.cs`挂载到Main Camera	Hierarchy → Main Camera → Add Component → GameManager	Play模式下，Console是否输出`GameManager initialized`	⚠️（运行验证）
23	创建空场景`scenes/main.unity`	Assets/ → scenes/ → Right Click → Create → Scene	Build Settings中是否显示此场景	⚠️（场景管理）
24	将`main.unity`设为Active Build Scene	Build Settings → Scenes In Build → Check`main.unity`	Build按钮是否可点击	⚠️（构建前提）
25	执行Build → Android → Build，生成APK	Build Settings → Build	APK文件是否生成，且大小>5MB（排除空包）	⚠️⚠️⚠️（构建成功）
26	将项目根目录的`.gitignore`替换为Unity官方版	GitHub → unity-jenkins-build → .gitignore	Git Status是否显示`Assets/Plugins/`等应忽略目录未被追踪	⚠️⚠️（Git安全）
27	Commit并Push所有变更（含.meta文件）	Terminal → git add . && git commit -m "init: unity config & structure"	团队成员Pull后，能否100%复现相同环境	⚠️⚠️⚠️（协作终局）

这份清单不是一次性的。它应被刻入团队的CONTRIBUTING.md，成为每个新成员入职第一天的实操考试题。我坚持让实习生在入职首日，独立完成这27项，并提交录屏。通过者，才被允许接触业务代码。因为真正的Unity高手，不是最会写Shader的人，而是最清楚Assets/目录下每一个.meta文件为何存在的那个人。

我在实际使用中发现，把第1项（Visible Meta Files）和第26项（正确.gitignore）做成Git Hook自动检查，能拦截83%的协作事故。具体做法：在项目根目录创建.husky/pre-commit脚本，检测Assets/下是否存在未提交的.meta文件，以及Library/、Temp/是否被意外提交。这个小技巧，让我们的Git仓库纯净度从62%提升至99.8%。