做游戏界面的时候，我几乎每隔一段时间就会碰到同一条报错：一堆UI按钮叠得好好的，结果画面里放个粒子特效，不是被界面盖住，就是把按钮全糊住了。老手一看就知道是UGUI和粒子特效的显示层级问题，但头一回遇到的人，往往卡一整天都不知道去哪调。今天我不打算给一个“抄了就能跑”的代码片段就算完事，而是把这条链路完全扒开。

这个问题的本质，是两套完全不同的渲染体系撞到了一起：UGUI走的是Canvas渲染流程，靠层级、SortingOrder和Canvas自身设置管理先后；而粒子特效走的是传统3D渲染管线，交给相机、深度缓冲和RenderQueue决定谁在前面。你如果不懂这两套体系各自的规则，就会在各个参数之间来回试错，调了没效果，关了又出问题。这篇内容适合那些已经在Unity里写过界面、放过特效、结果卡在层级上抓狂的开发者，也适合想从原理层面一次性搞懂UI和粒子为什么“打架”的人。

我先说明一个基调：这篇不是抄官方文档，是按我实际项目中踩过的坑、翻过的源码和验证过的方案来写的。你会看到为什么有些操作能成、有些是玄学，以及面对不同需求场景时，到底选哪种处理方式更稳。

1. 需求拆解：到底是谁在跟谁抢层级

1.1 它不止是一个显示问题

先看这个标题的词组：“UGUI和粒子特效显示层级问题”。如果只把它理解成“特效没显示出来”，那格局就小了。在实际项目里，这个问题的表现形式可以分成好几种：按钮上的点击光效被按钮自身遮挡、抽卡翻牌后的烟花被别的UI面板盖住、3D场景里的火焰想显示在血条上方、或者倒计时数字和粒子爆炸的先后关系错乱。

再往深一层看，所谓“显示层级”其实是两条线的交叉：一条是时间和空间上的遮挡关系，另一条是不同的渲染命令提交给GPU的先后顺序。也就是说，你以为你在调“谁在前面”，实际上你调的是“显卡先画谁、后画谁”。

搞明白这个根本，才不会出现那种“我明明把粒子放到了UI最上层怎么还不显示”的困惑。放得靠上只是Hierarchy顺序，不等于渲染顺序。

1.2 标题背后的隐藏需求

很多刚接触Unity的人，搜“UGUI粒子层级”其实是想要一个“点赞特效”。网上那些爱心粒子表白HTML之所以能戳中很多人，就是因为“粒子特效在UI上飘起来”这个动作背后，隐藏着一连串需求：社交互动、战斗反馈、抽卡演出、弹窗装饰、新手引导高亮。

所以我把这篇文章的实操重点放到三件事上：一是把UGUI的层级体系讲透，二是把粒子的渲染原理讲清楚，三是给出几种马上能用的方案，并且告诉你每种方案背后的代价。

2. UGUI渲染层级的底层逻辑，先吃透再动手

2.1 Canvas是UI世界的“总调度”

在理解层级问题之前，首先要建立一个大前提：UGUI里的所有东西，包括Image、Text、Button、RawImage，都不是传统意义上的3D网格。它们最终会被各自的Graphic组件生成顶点数据，然后由CanvasRenderer提交并合成一个或多个大Mesh，交给Canvas统一渲染。

Canvas自身有三种Render Mode：Screen Space Overlay、Screen Space Camera、World Space。你项目里的UI层级问题，多半跟第一种和第二种有关。

• Screen Space Overlay模式下，UI不经过任何相机，直接画在屏幕最顶层。它永远显示在3D世界的物体前，包括粒子。
• Screen Space Camera模式下，UI会被指定的UI相机渲染，渲染后的画面作为相机画面的一部分叠加到主相机输出之上。
• World Space模式下，UI像3D物体一样摆在世界里，需要相机看到才能显示。

很多人问我：为什么UI里放了个粒子，一下子把整个界面挡没了？答案就在这里。如果Canvas是Overlay模式，粒子又不归Canvas管，那粒子会被当成一个世界里的3D对象。当它出现在相机视口内时，因为它可能在UI之前渲染，也可能在UI之后，结果就是层级完全不可控。

想要UI和粒子统一管理，就必须让粒子也进入Canvas的渲染流程，或者至少让两者的渲染顺序可以被预测。

2.2 SortingOrder、Hierarchy顺序和Canvas嵌套

在同一个Canvas下，UGUI的绘制顺序有一条铁律：Hierarchy里靠下的组件会显示在靠上的组件前面。很多人背这句话，但不知道为什么。其实是因为UGUI遍历Canvas下的所有Graphic时，是按Hierarchy节点顺序收集的，后收集到的顶点数据会追加到同一批Mesh后面，而GPU绘制时后画的自然会覆盖先画的。

跨Canvas的时候，这条铁律就不再是唯一判据了，还要看每个Canvas组件的SortingOrder。SortingOrder越大，这个Canvas整体画得越晚，显示越靠前。这个属性在Canvas组件面板上直接可以调，也可以在代码里赋值。

Canvas还可以嵌套。子Canvas会跟随父Canvas的渲染顺序，但子Canvas自己也可以有独立的SortingOrder。这套机制在复杂界面里特别有用：比如你有一个主界面Canvas，一个弹窗Canvas，再加一个特效Canvas。只要给特效Canvas设一个比较大的SortingOrder，特效就能稳定盖住主界面和弹窗，但不会盖住你不想被盖住的东西。

这里有个常见误区：不是所有UI都必须放同一个Canvas下。很多人一开始就建了一个巨大的Canvas，把全界面所有元素都塞进去，然后为了调整某个特效和某个按钮的先后，只能在Hierarchy里反复拖节点。这样做能解决，但维护成本极高。

2.3 渲染原理和RenderQueue的交叉点

UGUI的CanvasRenderer最终提交渲染时，用的是透明渲染队列。Unity的渲染队列按值分类，比如Background是1000，Geometry是2000，AlphaTest是2450，Transparent是3000，Overlay是4000。

UI的CanvasRenderer提交上去的物体，默认RenderQueue落在3000附近。粒子的材质RenderQueue则通常也是3000。问题就出在这：两者都在同一个队列里，谁先谁后就要看相机的深度和物体的RenderOrder，而这两个因素的组合方式，在不同项目里千差万别。

这也就是为什么有些人把粒子的RenderQueue改成3001、3002，就能稳定盖住UI。因为RenderQueue比UI高，GPU在透明队列里会按这个值从低到高逐个绘制，队列值大的后画，后画的自然在上面。

但只说RenderQueue并不完整。3D粒子还要经过深度测试，如果主体深度被UI挡了，即使RenderQueue改得很大也可能被裁剪掉。所以仅仅改RenderQueue，在Unity的某些版本或某些平台上会失效，需要配合ZTest的设置。

3. 粒子特效为什么总在UI层级里“失控”

3.1 粒子的渲染出身决定了它的“户籍”

粒子系统在Unity里用的是ParticleSystem组件，实际负责渲染的是ParticleSystemRenderer。这个Renderer的本质是MeshRenderer的变种，也就是说粒子的渲染流程和3D物体是一模一样的：它有自己的Transform位置，有材质，有RenderQueue，参与深度测试，受相机裁剪影响。

一个3D世界的物体跟UI放在一起，本来就不该有稳定的遮挡关系。你在Hierarchy里把粒子拖到Canvas底下，并不会改变它的3D属性，顶多让它逻辑上待在Canvas下面，渲染时还是走3D管线。

很多新手在这里就会懵：为什么我把粒子拖进Canvas，它还是不跟UI走？因为它压根不是UI，拖进Canvas只是骗自己，Canvas压根不渲染它。

3.2 透明队列内部的先后顺序

从渲染队列的维度看，粒子属于Transparent队列，UI的CanvasRenderer也属于这个队列。在同队列内部，Unity对物体的排序规则是：如果脚本里指定了RenderQueue的具体值，按值排；值相同的情况下，按距离相机远近排；如果还有SortingLayer和Order in Layer，再按这两个属性排。

这就导致一个非常常见的现象：粒子明明在屏幕中心，但它和UI在同一个RenderQueue值下，位置有时比UI“离相机近”，有时候又比UI“离相机远”，结果就是在某些角度下正常，换个角度层级就反转了。你以为是相机旋转引起的，其实是排序规则在反复横跳。

3.3 摄像机深度与渲染顺序的叠加影响

当Canvas使用Screen Space Camera模式时，渲染结果还受一个因素影响：UI相机的Depth值。相机Depth越大，这个相机整体渲染越晚，画面越靠前。

如果粒子和UI在两个相机里分别渲染，你可以通过调相机Depth来控制层级。这确实是一种方案，但要注意：哪怕是同一个相机里，深度复杂的情况依然存在。比如UI相机深度比主相机大，但粒子是主相机渲染的3D物体，由于主相机先渲染、UI相机后渲染，UI依然会盖住粒子。这时候你要把粒子单独放进另一个Depth更大的相机，才能让粒子盖住UI。

听起来是不是有点像套娃？这就是为什么很多项目最终选择了“让粒子成为UI的一部分”这个方案。

4. 实操解决：让粒子乖乖待在UI层级里

4.1 方案一：多Canvas + SortingOrder（最通用）

这应该是门槛最低、最容易维护的方案。核心思想是：不要试图让3D粒子和UI在同一套体系里和睦相处，而是把它们拆到不同Canvas，再用SortingOrder控制谁先谁后。

具体操作步骤：

1. 确保你的主界面使用一个固定的Canvas，比如叫MainCanvas，SortingOrder设为0。
2. 新建一个空物体，挂上Canvas组件，取名为EffectCanvas。
3. EffectCanvas的RenderMode跟MainCanvas保持一致。如果你主界面用Overlay，这个也用Overlay，SortingOrder设为10或者其他大于MainCanvas的值。
4. 把粒子特效预制体放到EffectCanvas下。注意，粒子的位置需要按屏幕坐标或者相对特效锚点来摆放。
5. 运行，粒子就会稳定显示在MainCanvas之上。

如果你想控制“粒子在部分UI之上、部分UI之下”，可以再拆一层：把那些要盖住粒子的UI放到另一个SortingOrder更高的Canvas中。比如主UI是0，粒子是10，按钮提示是20，图标装饰是5，这样你就能精确控制每个层级的盖压关系。

这个方案最大的优点是不改动粒子本身，近景特效、UI动效都能直接用。缺点是Canvas数量变多，UI的Batch合并效果会变差，Draw Call可能上升。而且，如果粒子是屏幕空间特效，它的坐标转换你得自己管理，粒子不会自动跟着屏幕锚点走。

4.2 方案二：把粒子渲染到UI层（UIParticle）

这是2022年之后Unity官方推荐的路线。Unity在2022.2版本里加入了内置的UIParticle组件，直接作用在粒子系统上。它的工作原理是：截取粒子系统的渲染结果，把它转成CanvasRenderer可以处理的顶点数据，然后作为UI的一部分参与Canvas渲染。

这样的话，粒子就真正变成了“UI粒子”，你可以在Hierarchy里把它当作一个UI元素来排列，它的上下关系由Canvas内的层级和SortingOrder决定，完全可预测。

具体使用：

1. 在你的粒子物体上添加UIParticle组件（低版本Unity可以通过Package Manager搜索安装，或者用第三方的实现）。
2. UIParticle需要粒子物体挂在某个Canvas下，或者UIParticle自己会生成一个Canvas。
3. 在UIParticle的设置里，通常要指定粒子系统的Render Mode为Billboard、Stretch Billboard等。
4. 把粒子的材质确保是支持透明渲染的普通粒子材质。
5. 设置之后，粒子就可以像Image一样跟UI交互，它的坐标可以由RectTransform控制，也可以通过一个自定义的跟随脚本来更新。

要注意的是，UIParticle组件并不是粒子系统的官方扩展那么简单，它内部会重写ParticleSystemRenderer的渲染逻辑，所以在某些自定义Shader、变形器或特定粒子Module下，可能会有兼容性问题。我自己遇到过温度贴图或自定义顶点流失效的情况，这时候就得考虑换方案。

4.3 方案三：RenderQueue和材质调整（险招但有效）

如果你不想拆Canvas，也不想用UIParticle，那就得跟渲染队列“肉搏”。基本思路是把粒子的材质RenderQueue提升到3000以上，让它比普通UI画得更晚。

具体操作：

1. 找到粒子使用的Material，在Inspector面板里把Shader的RenderQueue从Transparent（3000）改成Overlay（4000），或者手动输入一个介于3000到4000之间的数值，比如3050。
2. 注意，这个修改要基于复制的材质，不要直接改粒子的默认材质，否则会影响其他使用同材质的粒子。
3. 如果你的粒子被UI深度裁剪，还需要调整材质的ZTest为Always，并关闭深度写入，确保粒子不会被已绘制的UI深度挡住。
4. 在粒子系统Renderer模块里，把Sorting Fudge或Order in Layer调整一下，确保同队列内靠后。

这套方法最坑的地方在于：一旦你界面上有多个Canvas、多个相机，改RenderQueue之后的行为变得极难预测。我建议只用于临时验证效果，或者在极简UI场景下用。真要上正式项目，还是用方案一或方案四更稳。

4.4 方案四：用SortingGroup，把渲染分层再做一层包装

SortingGroup允许你把一组3D渲染器归到同一个排序组里，为其指定Sorting Layer和Order in Layer。虽然它不改变渲染队列，但能帮你管理世界空间里多个粒子的先后关系。

比如你有两个粒子特效，一个代表烟雾，一个代表火花，这两者在3D世界里本来就要有固定的顺序，那么把它们放在同一个SortingGroup下，再在SortingGroup上设置一个优先级，就能避免它们的顺序乱跳。

SortingGroup和UI的关系主要体现在：SortingGroup可以参与和SpriteRenderer、CanvasRenderer之间的排序。也就是说，在某些情况下，一个带有SortingGroup的粒子，可以跟UICanvas一起参与整层排序。

不过据我实测，SortingGroup对Canvas的排序生效时有额外条件，不是在所有Unity版本里都能直接跟UI“同台竞技”。所以这个方案更适合3D场景内部的特效管理，UI和粒子的跨体系问题还是留给前面三个方案。

5. 源码层面的理解与排查技巧实录

5.1 看UGUI源码时盯住哪几个类

如果你决定深入源码，不要从渲染最底层开始读，那样会把自己绕晕。我建议围绕这几个关键类往下查：CanvasUpdateRegistry、Graphic、CanvasRenderer、GraphicRaycaster。

CanvasUpdateRegistry负责注册所有需要更新的UI元素，并在特定时机触发网格重建；Graphic是所有UI元素的核心，负责生成顶点数据；CanvasRenderer负责把顶点数据提交给Canvas；GraphicRaycaster负责射线检测，处理点击。

界面元素层级顺序之所以跟Hierarchy有关，是因为Canvas在收集子物体时，会按树的深度优先遍历，这个顺序被记录在CanvasRenderer的渲染顺序里。你可以在源码里看到Graphic的depth属性是如何影响射线检测优先级和渲染排序的。

粒子这边主要看ParticleSystemRenderer的源码注释和渲染流程，重点看RenderMode和Baked Mesh的提交方式。理解了提交方式，你就知道UIParticle为什么能把粒子转成UI网格，以及它的性能开销在哪里。

5.2 常见Bug排查实录

这里整理一下我实际项目里遇到过的典型问题和排查顺序：

第一个问题，也是最常见的：粒子明明放在UI元素上层，运行后被UI盖住。先看粒子物体是否真的在Canvas下；再查粒子材质RenderQueue；再查是否存在多个Canvas的SortingOrder冲突；最后查粒子Render Mode是不是World Space，如果是，位置坐标是否已经超出相机的近裁剪面。

第二个问题：粒子挂在Canvas下却不跟随UI移动。这多半是因为粒子还是3D坐标。你可以把粒子放到某个UI节点下，但它的坐标写入仍然是世界坐标。解决办法是给粒子物体加一个脚本，每帧把RectTransform的position转成世界坐标赋值给粒子Transform，或者直接用UIParticle。

第三个问题：粒子在编辑器里正常，打包到安卓或iOS上层级乱掉。这通常和移动端GPU的深度缓冲精度、半透明排序策略有关。移动端的排序规则跟桌面不完全一样，RenderQueue优先级高，但深度测试的误差也可能更大。这种问题很难彻底根治，最实际的办法是减少对深度测试的依赖，尽量把粒子做成UI的一部分，或者调整相机的远近距离让深度精度更高。

第四个问题：UIParticle在部分机型上出现闪烁或者撕裂。这通常是因为粒子数量太大、顶点数据更新频率过高，导致Canvas的网格更新跟不上。遇到这种情况，要么降低粒子数量，要么把粒子模块里的SimulationSpace改为World，再要么在低端机上关闭部分粒子模块。

5.3 避坑建议

做UI和粒子层级时，最容易让人崩溃的是“改了参数没效果”。我建议你养成一个习惯：改任何参数之前，先打开Frame Debugger，看看当前这一帧里到底是谁在什么时候被绘制。Frame Debugger能看到每一帧的所有渲染命令，包括UI和粒子的Draw Call，以及它们各自属于哪个渲染队列。这能帮你确认改动是否真的生效。

还有一个经验是：不要在一个场景里混用两套以上的方案。比如你既用了多Canvas排序，又给粒子改了RenderQueue，同时还想用UIParticle的某个模块，三套逻辑叠加在一起后，出问题你都不知道从哪里排查。我一般是这样定的：主业务UI全是Canvas，需要跟UI强耦合的粒子一律进UIParticle；全屏大特效才单独放一个高SortingOrder的Canvas；3D场景里的粒子用SortingGroup管理，不碰UI。

另外，粒子特效在UI里最容易犯的性能错误，是把粒子系统放到Canvas下的同时粒子数量还高得离谱。一个粒子就是一个或几个顶点，当Canvas理合批次时，这些顶点都会占用UI Mesh的缓冲区。如果粒子数量上千，UI的Rebuild开销会明显增加，卡顿就是这么来的。

关于爱心粒子表白那种页端效果，其实Unity里也有类似做法：用粒子模拟一堆小爱心从底部飘起，放在聊天界面或点赞按钮上方。这种效果用方案一就能轻松实现，关键是粒子的贴图要透明，RenderMode要Billboard，并且粒子物体要放在特效Canvas下。如果你还想加点交互，比如点按钮才触发，就写个脚本控制Play和Stop。

我在做这类效果的时候，还习惯把粒子的SimulationSpace设置成Local，这样粒子在移动设备上旋转屏时不会飘到屏幕外。要是UI本身会做缩放，那就得把RenderMode下的Scaling Mode改成分辨率缩放匹配，不然粒子大小会和预期差很多。

6. 从需求到落地的选择矩阵

为了让不同需求的读者直接“抄作业”，我把典型的场景和推荐方案整理成一个表格，你可以按自己的情况挑。

选择方案时，还有两个容易被忽略的因素：一是Canvas数量多会带来Overdraw，特别是在移动端；二是粒子的分辨率如果太高，就算进了UI Canvas，也有可能导致Canvas纹理更新过大。通常我的做法是先按需求选方案，再压粒子数量和贴图大小，最后在真机上跑帧率验证。

另外，推荐在项目里建立一个公共的特效层级管理脚本，用一个枚举定义UI特效的层级，比如UnderPanel、Normal、OverPanel、TopAlways，然后用代码统一为特效Canvas设置SortingOrder。这样美术和程序在放置特效时不需要手动填数字，只需要选一个层级档位，出错率会大幅降低。

我自己的项目就吃过“每个界面各自写死SortingOrder”的亏，后来发现同一个弹窗在不同界面里层级不一致，排查起来头皮发麻。统一脚本管理之后，坐标、层级、跟随逻辑都放进去，后面做新界面基本不会再碰到粒子遮挡问题。

7. 结束语

说到底，UGUI和粒子特效的显示层级问题，核心不是某个参数的技巧，而是理解“UI是一套Canvas渲染流程，粒子是一套3D渲染流程”这个根本事实。只要你能把粒子的渲染归属明确到其中一套体系里，层级就不会乱。多Canvas配SortingOrder适合讨巧，UIParticle适合做精致UI粒子，RenderQueue是急救手段，SortingGroup则是3D场景里的秩序管理器。

我个人在实际项目中养成的习惯是：不管需求多急，先花十分钟打开Frame Debugger看清楚问题出在哪个阶段，再动手改参数。这十分钟通常能省下后面一两个小时的折腾。最后再提一个细节——粒子的Renderer模块里有一个Sorting Fudge，这个值很多人忽略，它影响粒子在同RenderQueue下的绘制位置微调，某些层级错乱问题把这里的值从0改成-1或者1就能解决，值得一试。