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、NDK |
| WebGL 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"，或者更简单粗暴的做法——养成一个肌肉记忆：每次点播放键之前先按 Ctrl+S。同样的道理也适用于预制体的编辑，在预制体编辑模式里改完一定要点一下返回箭头，不然改动可能没被应用。
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() { GetComponent<Rigidbody>().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 = GetComponent<Rigidbody>(); } 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 的alpha+blocksRaycasts+interactable三件套，比反复 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 Size，Reference Resolution 填你的设计稿尺寸（常见 1920x1080），Match 值横屏项目往 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 里 | 改到 LateUpdate |
5.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 里，所有"批量操作"之前先备份，所有"删除"之前先归档。这两句话听起来像废话，但我每次偷懒跳过它们的时候，基本都会付出几倍的时间代价。
