0. 先把话说明白为什么新手第一课往往不是写代码刚接触 Unity 的人十个里有八个第一周就卡在跟写游戏没什么关系的事情上装了两三个版本互相打架、项目文件夹挪了个位置结果所有引用全丢、Hub 里删了项目以为万事大吉结果云端还挂着一堆构建任务在烧额度。我自己当年也是这么过来的把编辑器装到带中文和空格的路径下然后花了整整一个下午排查资源导入失败的问题最后发现只是路径里多了一个空格。这篇东西想聊两件事。前半段是 Unity 初学阶段真正该先立住的规矩包括版本选择、项目目录的边界、脚本生命周期的常识、性能意识从第一天怎么培养后半段是很多人问过的云端项目怎么删也就是 Unity 云端项目Cloud Project、配套仓库和构建目标的完整清理流程。关键词就三个Unity、云端项目、删除云端项目前两个贯穿全文最后一个集中在第 3、第 4 章。适合谁看完全零基础、刚下载完 Unity Hub 准备开第一个工程的人做了一两个月 Demo 但项目结构一团乱、想回头补基础的人以及手上攒了一堆试验性云端项目、想彻底清理掉的人。不需要任何前置知识但我假设你至少打开过一次编辑器知道 Assets 面板长什么样。先说一个反常识的结论Unity 初学阶段最值钱的能力不是写脚本而是知道什么东西可以删、什么东西删了就回不来。云端项目这块尤其典型Hub 列表里的删除按钮和真正的删除完全是两码事搞混一次可能就要重建整个工程的版本历史。1. Unity 初学阶段最该先立住的五条规矩1.1 版本选择的逻辑为什么我建议新手一律从 LTS 起步Unity 的版本线大致分成两类LTS长期支持和技术预览/正式新版本。新版本号看起来诱人功能最新教程视频也多是拿最新版录的。但我给新手的建议非常明确——除非你明确要用某个只有新版才有的特性否则一律从当前 LTS 起步。理由有三层。第一层是教程适配网上大部分成熟的中文教程、插件、开源工程都围绕 LTS 打磨过你跟着做不容易撞上这个 API 在新版被改名了这类破事。第二层是插件生态很多 Asset Store 资源包的兼容区间写的是某几个 LTS 版本新版装上去会报一堆编译错误而新手往往分不清是插件的问题还是自己的问题。第三层是回滚成本LTS 的补丁版本之间升级基本平滑而跨大版本升级经常会触发 API 更新向导API Updater改完一堆脚本之后你自己都不知道改了什么。这里有个非常具体的操作建议同时只保留两个版本。一个是主力的 LTS用来做正经项目另一个是当前最新稳定版用来尝鲜和看新特性。装三四个版本之后Hub 里到处都是同名工程你会记不清哪个工程是用哪个版本建的打开时弹出升级提示手一抖点了确认工程就再也回不去了。1.2 安装路径和模块勾选两个看起来无关紧要、实际天天坑人的点安装路径这件事我踩过的坑足够写一整页。核心原则就一句全英文、无空格、尽量短最好放在 SSD 上。像D:\Unity\Hub和D:\Unity\Projects这种结构是最省心的。中文路径、带空格的路径、放在 OneDrive 同步目录下的路径这三类都容易引发资源导入异常、构建失败、缓存错乱之类的玄学问题而且报错信息往往跟真实原因差得很远新手根本没往路径上想。至于模块Module勾选很多人装的时候一顿全选结果硬盘被吃掉六十个 G。实际按需勾模块什么时候需要备注Windows Build Support (IL2CPP)出 Windows 包默认只有 Mono需要额外勾Android Build Support手机、XR 设备开发要连带勾 OpenJDK、SDK、NDKWebGL Build Support发布网页版包体大构建慢吃内存iOS Build Support出 iOS 包还需要一台 Mac 做最终构建Documentation想离线查 API体积不小网速好的话可以不装Android 那一行特别说明一下必须把 OpenJDK、Android SDK、NDK 三个子项一起勾上让 Unity 自己管理。不要图省事去用系统里已经装好的那一套版本对不上时的报错会让你怀疑人生。做 XR 设备开发比如 PICO 4 这类一体机的同学走的就是 Android 这条链另外还要在 Package Manager 里装 XR 相关的包这是另一个话题了。1.3 项目目录的边界哪些文件夹能删哪些碰都不能碰这是新手最容易出事的地方。一个 Unity 工程根目录下的东西大致分两类我按能不能进版本管理来分类比按功能分类实用得多绝对不能删、必须进版本管理的Assets、Packages、ProjectSettings。这三个文件夹是你工程的真正本体。Assets里是资源和脚本Packages里是依赖清单ProjectSettings里是项目设置。丢了任何一个工程基本等于重建。可以随便删、会自动重建的Library、Temp、obj、Logs、UserSettings。Library是导入缓存删掉之后重新打开工程会全量重新导入一遍耗时但无害。这也是为什么工程莫名其妙坏了的时候第一步永远是关掉 Unity、删掉Library、重新打开——能解决相当大比例的诡异问题。不能手动挪动的Assets里面那些.meta文件。每个资源旁边都有一个同名的 meta 文件里面存着 GUID 和导入设置。你在文件管理器里剪切粘贴资源、或者删掉 meta 文件Unity 就会认为这是一个新资源所有引用它的预制体、场景、材质全部变成 Missing。所有资源的移动、改名、删除一律在 Unity 的 Project 窗口里做这个习惯从第一天就要养成。提示在文件管理器里操作 Assets 目录是 Unity 新手最高频的自毁行为没有之一。哪怕你只是想给文件夹改个名也请在编辑器里改。1.4 第一天就配好版本管理别等出事再补我见过太多人第一个 Demo 做完才想起来要备份这时候想回溯一个昨天还能跑今天跑不了的改动已经没机会了。所以我的建议是新建工程的第一件事是配好 Force Text 序列化和 .gitignore第二件事是提交一次。Force Text 在 Edit → Project Settings → Editor → Asset Serialization 里改成 Force Text。默认的 Mixed 模式会让部分资源存成二进制Git 根本没法做差异对比冲突了只能二选一非常痛苦。.gitignore至少要包含下面这些[Ll]ibrary/ [Tt]emp/ [Oo]bj/ [Bb]uild/ [Bb]uilds/ [Ll]ogs/ [Uu]serSettings/ .vs/ .idea/ *.csproj *.sln *.user注意我没有把Assets、Packages、ProjectSettings放进去它们是必须提交的。另外.meta文件也必须提交别听某些教程说meta 是自动生成的不用管那是不对的。1.5 编辑器里的一个隐藏开关先保存场景再运行顺手提一个救过无数人的设置。Unity 默认允许你在场景没保存的情况下点播放运行结束之后改动会全部丢掉。新手经常遇到我明明调好了一停就变回去了的困惑就是这个原因。在 Edit → Project Settings → Editor 里找到Enter Play Mode Options或者更简单粗暴的做法——养成一个肌肉记忆每次点播放键之前先按 CtrlS。同样的道理也适用于预制体的编辑在预制体编辑模式里改完一定要点一下返回箭头不然改动可能没被应用。2. 脚本与场景阶段新手最常撞上的三类问题2.1 生命周期搞不清就会出现为啥我的变量是空的MonoBehaviour 的生命周期顺序新手至少要记住这几个主干Awake→OnEnable→Start→ 每帧的Update→ 每帧固定步长的FixedUpdate→ 每帧最后的LateUpdate→OnDisable→OnDestroy。为什么顺序重要举两个最典型的场景。第一如果你在Awake里访问另一个脚本的公开变量而那个变量是在对方Start里赋值的你拿到的就是 null然后报 NullReferenceException。第二摄像机跟随必须写在LateUpdate里因为角色的位置在Update里改完之后LateUpdate才执行摄像机跟的位置才是这一帧最终的位置写在Update里就会出现摄像机和角色轻微抖动跑得越快抖得越明显。FixedUpdate和Update的区别也值得说清所有物理相关的操作Rigidbody 的力、速度、射线检测的时序敏感部分写在FixedUpdate因为物理引擎是按固定步长推进的默认 0.02 秒一次。而输入读取、动画触发、UI 逻辑这些写在Update。还有一个新手高频问题同一个脚本被挂了两次。表现是Update里的逻辑跑了两遍比如伤害翻倍、物体位移速度变成两倍。遇到效果好像乘以了 N的情况先检查 Hierarchy 里是不是同一个组件挂了多个实例。2.2 获取组件的三种写法性能和可读性差得很远新手最常写的代码大概长这样void Update() { GetComponentRigidbody().AddForce(Vector3.up); GameObject.Find(Player).transform.position Vector3.zero; }这段代码能跑但问题不小。GetComponent内部要做一次组件查找放在Update里等于每帧查一次GameObject.Find更狠它要遍历整个场景的层级是 Unity 里出了名的慢操作。正确做法是在Awake或Start里查一次然后缓存到字段private Rigidbody _rb; private Transform _playerTf; void Awake() { _rb GetComponentRigidbody(); } void Start() { _playerTf GameObject.Find(Player).transform; } void Update() { _rb.AddForce(Vector3.up); _playerTf.position Vector3.zero; }如果不想用Find最稳的做法是给字段加[SerializeField]然后直接在 Inspector 里拖引用。这样既不依赖名字改名不会断也不依赖层级路径还能在编辑器里一眼看出引用有没有丢。2.3 性能意识从第一批资源开始培养别等卡了再优化很多人觉得性能优化是进阶话题跟新手无关。我的看法相反优化不是让你一开始就写极致代码而是让你别养成必然要返工的习惯。几个从第一天就该注意的点UI 的显示隐藏方式。这个问题在社区被讨论过无数次SetActive(false)、改localScale、还是把 UI 移出摄像机范围结论是分场景的。SetActive(false)会让整个 GameObject 从渲染和逻辑里彻底移除最省资源但每次开关会触发一次层级变化和组件的OnEnable/OnDisable如果你在Update里频繁开关它反而更贵。localScale Vector3.zero保留了对象但渲染器还会参与剔除计算实际上并不省多少。移出相机范围是最取巧的做法对象还在跑逻辑只是看不见。我的经验是低频开关打开背包、切换面板用 SetActive高频开关每帧闪烁的效果才考虑改 localScale 或调 CanvasGroup 的 alpha。真正需要连续的显隐过渡用 CanvasGroup 的alphablocksRaycastsinteractable三件套比反复 SetActive 平滑得多。按钮点不中的问题。这也是新手非常高频的困惑——明明按钮就在那儿点击却没反应。常见原因有四个一是按钮上层的某个透明 Image 把射线挡住了它的 Raycast Target 没关二是按钮本身的 RectTransform 太小文字溢出到了外面但点击区域只有那一个小方块三是 Canvas 上没有 Graphic Raycaster 组件或者场景里没有 EventSystem四是点了但被别的 canvas 以更高的 Sorting Order 盖住了。放大点击范围最干净的做法是在按钮下面加一个透明的 Image 作为命中区域把它的 Color 的 alpha 设成 0保留 Raycast Target然后把这个 Image 的 RectTransform 拉大到你想要的范围。相比直接放大按钮本身这种做法不会影响视觉布局也不会被 Layout Group 重新算回去。做背包拖拽那种交互时思路也是一样的实现IBeginDragHandler、IDragHandler、IEndDragHandler三个接口拖动时把CanvasGroup.blocksRaycasts设成 false 让射线穿过被拖物体松手时再设回 true否则永远检测不到放到了哪个格子里。Draw Call 和合批的直觉。你不需要现在就学会看 Frame Debugger但要知道两件事同一个材质、同一个图集的物体更容易被合批场景里成百上千个独立材质的物体一定会卡。所以在做第一个场景时草地、地砖、墙体这类重复元素尽量用同一个材质加不同 UV而不是每块砖一个材质。2.4 平台相关的小开关早点知道少走弯路有两个东西新手迟早会碰到。一个是宏定义Scripting Define Symbols在 Player Settings → Other Settings 里。它的用处是让不同平台走不同代码分支比如只在编辑器里打印日志、只在 Android 上调用某个原生能力。常用的内置宏有UNITY_EDITOR、UNITY_ANDROID、UNITY_IOS、UNITY_WEBGL写起来很直观#if UNITY_EDITOR Debug.Log(只在编辑器里生效); #endif另一个是分辨率适配。Canvas Scaler 的 UI Scale Mode 选 Scale With Screen SizeReference Resolution 填你的设计稿尺寸常见 1920x1080Match 值横屏项目往 Width 偏、竖屏往 Height 偏。Player Settings 里的 Default Screen Width/Height 只决定打包后启动时的初始窗口大小不影响适配逻辑这两个概念别搞混。顺便说一个坑构建出来的GameAssembly.dll是 IL2CPP 后端的运行时产物属于构建输出千万不要把它拖进 Assets 目录。它跟工程本身没有关系放进去只会让工程变大、打包时多一份无用资源。同理构建输出目录Build/Builds也应该排除在版本管理之外。3. Unity 云端项目到底是个什么东西3.1 云端项目、仓库、构建任务是三层不同的东西很多新手把云端项目当成一个整体其实它至少包含三层第一层是项目本体。你在 Unity Hub 的 Projects 页面里能看到一个 Cloud 分区里面列的就是你账号下关联的云端项目。它本质上是一个项目容器记录了项目名称、所属组织、成员权限、关联的仓库地址等等。第二层是版本控制仓库。云端项目通常会绑定一个 Unity Version Control原来的名字叫 Plastic SCM仓库你的提交记录、分支、变更集都在这里。仓库可以是空的也可以有几百个变更集。第三层是构建目标Build Target和构建历史。如果你开过 Build Automation云端会按你配置的目标平台定期拉代码、跑构建、产出安装包。这一层是最容易被忽略的——构建任务会持续消耗你的额度删了项目本体但没管构建目标额度照样烧。把这三层分清楚删除云端项目这个操作才有意义。因为你会发现Hub 上那个删除按钮、网页控制台上的删除按钮管的是不同的层。3.2 什么情况下才真的需要删云端项目不是所有看着碍眼的云端项目都值得删。我按处理成本从低到高排一下只是不想在 Hub 里看到它。这种情况不要删只要把 Hub 里同步到本地的云端项目移除列表就行云端一切照旧。只是网页控制台里列表太长。可以先归档Archive归档后不在活跃列表里显示但数据和仓库都还在需要的时候能恢复。这是最稳妥的选择。试验性质的项目做完就废弃。这种才是真正适合删的。删之前确认没有还需要的提交记录、没有挂在里面的构建任务、没有别人还在协作。如果是团队项目删除前一定要跟成员打招呼。额度快用完了想清一批。这时候重点不是删项目而是先关掉所有构建目标和自动构建计划。构建不是白跑的关掉之后额度立刻就不烧了项目本身留着也不占多少。我自己的习惯是试验项目一律先归档过一两个月确认完全用不到再删。删除有恢复期但恢复期过了就真的没了多等两个月的成本远低于误删一个还有用的仓库。3.3 删除前的检查清单在你点下任何一个删除按钮之前把这几条过一遍本地是不是有完整的工程副本没有的话先完整复制一份到另一个目录。本地工程的版本控制是不是已经断开还连着的话删除云端仓库后本地会一直弹登录窗口。有没有别的成员在这个项目里有的话先确认。有没有正在跑的构建任务去 Build Automation 页面看一眼。有没有关联的付费额度或者席位删之前把席位释放掉。项目名称和 ID 记下来了吗如果你打算以后重建一个同名项目记下 ID 能帮你区分。注意删除是不可逆操作的最后一步。Unity 云端项目删除后通常有一段恢复窗口窗口期内可以在控制台里恢复超过窗口期就找不回来了。具体天数随官方策略调整别把恢复期当成保险。4. 最新版 Unity 里删除云端项目的完整实操4.1 Hub 里的操作分清移除列表和删除项目打开 Unity Hub左侧切到 Projects找到 Cloud 分类。在较新的 Hub 版本里项目卡片右上角有一个三点菜单展开之后会看到类似 Remove from list 和 Open in Cloud Dashboard 之类的选项。关键就在这里Remove from list 只是把这条记录从你本机 Hub 的列表里去掉云端项目、仓库、构建全部原封不动。下次你在网页控制台里登录它还在那儿如果你在 Hub 里重新同步云端项目它又会出现。很多人以为点了这个就是删了然后过几天发现额度还在降一脸懵。所以正确的姿势是Hub 只用来做清理本机列表这件事真正的删除去网页控制台。如果你在 Hub 的菜单里确实看到了带删除语义的选项不同版本命名不一样有的叫 Delete有的叫 Remove project点它的时候也留意一下弹窗里的文字描述它会告诉你这是本地移除还是云端删除。看弹窗描述不要凭按钮名字猜。4.2 网页控制台真正的删除在这里真正的删除流程走浏览器。整体路径大致是这样界面随版本变化但层级逻辑是稳定的用你的账号登录 Unity Cloud 控制台。顶部或左侧切换到你要操作的组织Organization。注意这一步很关键如果你有多个组织在错的组织里找半天也找不到项目。进入 Projects 列表找到目标项目点进去。在项目的 General / Settings 页面里往下翻到底部会有一个危险操作区域Danger Zone 或类似命名。点击 Delete project系统一般会让你手动输入项目名称来二次确认。确认后项目进入删除状态在恢复窗口期内可以在控制台的已删除列表里找到并恢复。权限问题值得单独说一句如果这个区域里没有删除按钮或者按钮是灰的八成是你的角色权限不够。云端项目的删除一般需要组织所有者Owner或具备管理权限的角色。如果你只是被邀请进来的成员看不到删除入口是正常的需要找项目创建者操作。4.3 顺手清理仓库和构建目标这一步最容易被漏掉删完项目本体别急着关页面。回到组织层面的菜单检查两处第一处是版本控制仓库。在组织的版本控制/仓库列表里看看还有没有跟这个项目同名的仓库残留。有些情况下项目删了仓库还独立存在尤其是你当初手动创建仓库再关联到项目的那种。第二处是构建目标Build Targets。在 Build Automation 里看看有没有属于这个项目的构建配置。构建配置会按计划自动触发只要它还在就会消耗你的构建时长额度。我见过有人删了项目本体但构建配置还挂在组织上每个晚上自动跑一次最后额度莫名其妙就没了。另外还有一个不太显眼的东西团队成员席位。如果这个项目是你唯一的项目删完之后可以考虑把不需要的席位释放掉这直接影响账单。4.4 用 REST API 批量清理适合攒了几十个试验项目的情况Hub 和网页控制台适合删一两个如果你攒了几十上百个试验项目一个个点会点到手软。这种情况可以走 Unity Cloud 的 REST API。整体思路分两步先拿一个服务账号的凭据在组织的 Service Accounts 里创建给它项目管理的权限再带着这个凭据去调删除接口。模板长这样具体路径和参数请以官方最新的 API 文档为准接口版本迭代比较频繁# 示意模板端点路径随官方版本变化务必查文档确认 curl -X DELETE \ -H Authorization: Bearer SERVICE_ACCOUNT_TOKEN \ -H Content-Type: application/json \ https://官方API域名/v1/organizations/ORG_ID/projects/PROJECT_ID写脚本的时候有几个我踩过的坑值得分享。第一先做一次 GET 列表把要删的项目 ID 全部导出来存成文件不要边查边删中间断一次你就不知道删到哪儿了。第二加限速短时间发太多请求会被限流建议每个请求之间至少间隔一秒。第三先拿一个废弃项目试跑确认接口行为和权限都对再跑全量。第四服务账号的密钥不要提交到 Git用环境变量传。还有个更保守的做法不要真删改成归档。如果 API 支持改项目状态的接口把项目标成归档效果上跟删掉差不多但心里踏实。等你哪天确定不需要了再统一下手删。4.5 删完之后本机上的残留怎么处理云端删了本地工程通常还在磁盘上而且还能正常打开。这时候有两种处理方式。如果你想继续用这个工程打开 Unity Hub用 Add project from disk或 Open → Add project from disk把本地目录重新加进来。加进来之后它就是一个纯粹的本地工程了跟云端没有任何关系。如果之前是连着版本控制的可能需要在编辑器里断开版本控制连接或者在工程目录里清理掉相关的配置否则 Unity 会一直尝试连接已经消失的远端。如果你想彻底清掉直接删本地目录。但注意Unity 工程的Library目录可能有几 GB删之前确认里面没有你忘了提交的改动。最稳的检查方式是打开工程看一眼场景能不能正常加载、控制台有没有报错。还有一个隐藏残留是 Hub 里的缓存条目。云端项目删完之后Hub 的列表里可能还留着一条打不开的记录点刷新或者重新登录账号通常就消掉了。5. 常见问题速查与踩坑记录5.1 问题速查表现象大概率原因处理方式Hub 里删了网页端还在只做了本地列表移除去网页控制台删项目本体网页端删了Hub 里还显示本地缓存未刷新重新登录账号或刷新列表找不到删除入口权限不足找组织所有者操作提示有构建任务在运行构建配置未清理先停用或删除构建目标删完额度还在掉构建计划仍在触发检查 Build Automation 的定时配置本地工程打不开了Library 缓存与版本不匹配删 Library 重新打开控制台一堆 Missing 引用meta 文件被破坏或误删从版本管理回滚别硬修脚本效果翻倍同一组件挂了多次检查 Hierarchy 里的重复实例按钮点不中射线被遮挡或区域太小关掉上层 Raycast Target加透明命中区摄像机跟随时抖动写在 Update 里改到 LateUpdate5.2 三个我印象最深的坑坑一把 Hub 的移除当成了删除。这是我最想提醒的一条。当时我在整理账号里的试验项目Hub 里一顿移除列表干干净净心情舒畅。两周后收到额度提醒进去一看那些已删除的项目全都活得好好的还有一个每天定时跑构建。教训就是任何删除操作都要在源头网页控制台确认一次。坑二在文件管理器里整理资源。工程做到一半觉得 Assets 下面太乱就在资源管理器里建文件夹、拖文件、改名字。回到 Unity整个场景一片洋红预制体上的引用全部丢失。原因是 meta 文件和资源文件的对应关系被破坏了。修复方式只能是从版本管理回滚如果没有版本管理那就只能一个个重新拖引用。从那之后我的原则是Unity 工程里的任何文件操作都在 Unity 里做。坑三用新版本打开老工程还顺手保存了。打开时弹了个升级提示我想着升就升吧点了确认编辑器开始转换资源转完之后一堆插件报错回不去了。正确做法是升级前先把整个工程目录复制一份出来在副本上试。如果非要在原工程上升级至少保证有一次可用的提交。5.3 关于 WebGL 和一些平台特有的小提醒如果你打算把工程发布成网页版有两个细节新手特别容易卡住。一是压缩格式Compression Format构建出来的.wasm、.data这些文件如果服务器没有正确的 MIME 类型映射浏览器会直接拒绝加载部署到 IIS 这类服务器上的时候需要手动给这些扩展名配上 application/wasm 之类的类型。二是 WebGL 对多线程和部分 API 有支持限制某些插件在 WebGL 平台上直接用不了选插件前先确认平台兼容性。另外顺嘴提一句构建产物目录不要放在Assets里面。有人图方便把 Build 输出到 Assets 下面的子目录结果 Unity 把构建出的资源又当成工程资源导入一遍工程体积暴涨、打包时间翻倍而且每次构建都在跟自己的上一次产物较劲。6. 最后分享几条我自己一直在用的习惯第一每个工程根目录放一个 README写上用的 Unity 版本号、依赖的插件版本、启动场景名。三个月后你回来改这个工程这三条信息能省你半小时。第二试验项目一律用带日期的命名比如test_shader_20240315。这样你在云端控制台里一眼就能看出哪些是废案批量清理的时候不用一个个点进去看。第三云端项目每季度清一次流程固定先在控制台看哪些超过 90 天没动过能归档的归档确定不要的先停构建、再删仓库、最后删项目删完在本地留一份完整的工程备份压缩包。这套流程走下来一次也就十几分钟比年底攒一堆再手忙脚乱强太多。第四遇到删不掉的情况先怀疑权限再怀疑缓存最后才怀疑是 Bug。云端的各类控制台界面状态更新有时候会滞后刷新一下、退出重登一下能解决的比想象中多。第五也是我最想强调的一条在 Unity 里所有批量操作之前先备份所有删除之前先归档。这两句话听起来像废话但我每次偷懒跳过它们的时候基本都会付出几倍的时间代价。