企业官网建设流程全解析

1. 项目概述：当粒子效果遇上UI世界

在Unity开发中，尤其是制作带有强烈视觉表现力的UI界面时，我们常常会遇到一个令人头疼的“夹层”问题：如何让那些酷炫的粒子特效，比如按钮点击时的火花、角色升级时的光芒、界面转场时的星尘，能够完美地嵌入到UI层级中，而不是要么被UI挡住，要么飘在UI之上破坏整体感？传统的做法要么是把粒子系统做成世界空间的，然后通过摄像机调整，控制起来非常笨拙；要么是使用Screen Space - Overlay的Canvas，但这样粒子又无法与UI进行正确的深度交互。这个痛点催生了一个在社区中广为流传的解决方案——ParticleEffectForUGUI插件，而它的核心魔法，就在于其精心设计的渲染排序算法，也就是我们今天要深入剖析的RenderingOrder实现。

简单来说，ParticleEffectForUGUI是一个专门为了让Unity的粒子系统（Particle System）能够像普通UI元素（Image, Text等）一样，在UGUI的Canvas里被正确渲染、受Mask裁剪、并能进行精确层级排序的插件。它解决的不仅仅是“显示”问题，更是“秩序”问题。想象一下你的UI是一个多层蛋糕，每一片水果、每一朵奶油花都需要放在正确的位置。RenderingOrder算法就是那个确保粒子这片“糖霜雪花”能落在蛋糕特定夹层，而不是掉在盘子外或者糊在另一朵花上的关键规则。对于任何需要将动态粒子效果与静态UI设计深度融合的项目，比如游戏主界面、抽卡动画、技能HUD、活动弹窗等，理解这套机制都至关重要。

2. 核心需求与挑战拆解

2.1 为什么UGUI原生不支持粒子排序？

要理解ParticleEffectForUGUI的价值，首先得明白UGUI（Unity GUI）的渲染逻辑。UGUI基于Canvas进行渲染，Canvas下的所有元素（我们称之为CanvasRenderer）的绘制顺序，默认是由它们在Hierarchy中的顺序决定的，从上到下，后渲染的会覆盖先渲染的。同时，UGUI有一套基于RectTransform的布局系统和基于Material的合批（Batching）机制来提升性能。

然而，Unity原生的粒子系统（ParticleSystem组件）是一个完全不同的渲染体系。它通常由ParticleSystem组件和ParticleSystemRenderer组件构成，其渲染是直接由引擎的图形管线处理的，与Canvas的渲染队列（Render Queue）无关。当你把一个带有ParticleSystem的GameObject作为Canvas的子物体时，你会发现它要么完全不显示（如果Canvas渲染模式是Screen Space - Overlay），要么作为一个独立于所有UI的“层”进行渲染（World Space模式），无法参与UI的层级排序，也无法被UI的Mask组件裁剪。

这里的关键矛盾在于渲染管线的割裂。UGUI的渲染是“即时模式”（Immediate Mode）的，每一帧根据Hierarchy顺序提交绘制命令。而粒子系统的渲染是“基于发射器”的，由ParticleSystemRenderer管理，它不关心自己在Hierarchy中的位置，只关心粒子的位置、大小和生命周期。因此，让粒子“融入”UI，本质上是要将粒子系统的渲染命令，“劫持”并融入到UGUI的渲染命令流中去，并赋予其一个可定义的排序值。

2.2 ParticleEffectForUGUI的核心目标

基于以上挑战，ParticleEffectForUGUI插件设定了几个明确的工程目标：

1. 同Canvas渲染：使粒子效果能够在任意类型的Canvas（Overlay, Camera, World）中，与其他UI元素在同一渲染流程中被绘制。
2. 受Mask约束：粒子必须能够被UGUI的RectMask2D或Mask组件正确裁剪，这是实现UI集成感的基础。
3. 精确层级控制：开发者必须能够像控制Image和Text一样，通过调整GameObject在Hierarchy中的顺序，或者通过代码指定一个排序值，来决定粒子层位于哪些UI元素之上、之下。
4. 保持粒子特性：在满足以上条件的同时，不能过度牺牲粒子系统本身的特性，如纹理动画（Texture Sheet Animation）、颜色随时间变化（Color over Lifetime）、大小随速度变化等。
5. 性能可控：解决方案需要高效，不能因为集成导致DrawCall（绘制调用）爆炸式增长。

RenderingOrder算法就是为了达成目标3和目标5而生的核心机制。它不仅仅是一个“排序值”，更是一套将粒子数据重新组织、并注入到UGUI渲染管线的完整策略。

3. 渲染排序算法（RenderingOrder）深度解析

3.1 算法总体架构与数据流

ParticleEffectForUGUI的渲染排序并非一个简单的数字比较。它是一个贯穿粒子更新、数据准备和渲染提交多个阶段的流程。我们可以将其核心数据流概括为以下几个步骤：

1. 粒子模拟与数据收集：在Update()中，插件会从Unity原生的ParticleSystem组件中获取当前帧所有存活的粒子数据，包括位置、颜色、大小、旋转、UV等。这一步是基础，数据来源是可靠的。
2. 排序键（Sorting Key）计算：这是算法的核心。插件会为每一个粒子计算一个“排序键”。这个键值决定了在最终渲染队列中，这个粒子的先后顺序。计算方式是可配置的，常见策略有：
   • 基于局部Z轴（Local Z）：使用粒子在其局部坐标系下的Z值。这允许你在粒子发射器内通过控制粒子的起始Z值来粗略排序。
   • 基于到摄像机的距离（Distance to Camera）：在World Space Canvas中常用，模拟3D物体的深度排序。
   • 基于自定义排序函数：插件允许你传入一个委托（delegate），根据粒子的任意属性（如生命周期、大小、自定义流）来计算排序键，实现非常灵活的排序效果，比如让新生成的粒子永远在最上面。
3. 粒子数据排序：根据上一步计算出的排序键，对所有当前帧的粒子进行排序（通常是稳定排序，如Array.Sort）。排序的顺序直接决定了它们被送入渲染队列的顺序。
4. 网格重建与合批：排序后的粒子数据，会被转换成网格（Mesh）信息。每个粒子通常对应两个三角形（一个四边形）。插件会智能地将多个粒子合并到同一个SubMesh中，前提是它们使用相同的材质（Material）和纹理（Texture）。这一步对性能至关重要，它减少了DrawCall的数量。
5. 注入CanvasRenderer：插件内部维护了一个或多个CanvasRenderer组件。它将重建好的网格、以及粒子材质，设置给这个CanvasRenderer。至此，粒子系统就“变身”成了一个特殊的UI图形元素。
6. 参与Canvas排序：这个内部CanvasRenderer的排序，由插件根据你的设置来控制。你可以通过一个公共的sortingOrder或sortingLayerID属性（模仿UI元素），或者简单地通过调整该GameObject在Hierarchy中与其他UI元素的相对位置，来决定这个“粒子UI块”在整个Canvas中的渲染层级。

注意：这里存在两个层次的排序。第一个是粒子之间的内部排序（步骤3），由RenderingOrder算法控制；第二个是粒子系统作为一个整体在UI中的层级排序，由UGUI的标准规则控制。ParticleEffectForUGUI巧妙地管理了这两者。

3.2 排序键的计算策略与性能权衡

排序键的计算策略是平衡效果与性能的关键。插件通常提供几种内置模式：

• 距离排序（Distance）：效果最符合3D直觉，粒子会根据与观察者的远近正确遮挡。但需要为每个粒子计算距离（涉及一次向量减法和平滑运算），在粒子数量巨大时（如数千个）会成为CPU端的性能瓶颈。适用于粒子数量较少、且深度效果重要的World Space UI场景。
• 出生顺序（Birth Order）：按照粒子被发射出来的顺序排序。计算开销最小，但视觉效果可能很混乱，后发射的粒子永远盖在先发射的粒子上，不符合视觉逻辑。除非追求特定效果，否则不推荐。
• Z轴排序（Local Z）：在发射器局部空间内，使用粒子的初始Z位置作为排序依据。性能很好，因为Z值在发射时就确定了。但要求你在设计粒子效果时，有意识地在Z轴上分布粒子。这是2D UI场景中最常用且高效的方案。
• 自定义排序：最灵活，也最危险。你可以写一个函数，例如(particle) => particle.remainingLifetime，让即将消失的粒子显示在底层。这带来了无限可能性，但也意味着每帧要对每个粒子执行一次你的函数调用，必须确保函数极其高效。

在我的实际项目中，对于绝大多数屏幕空间UI特效（如按钮反馈、图标高光），Z轴排序是首选。它的性能损耗可以忽略不计，并且通过粒子编辑器的“Start Speed”或“Velocity over Lifetime”模块给粒子一个很小的Z轴速度，就能轻松创造出有层次感的粒子流动效果，而无需复杂的计算。

3.3 网格重建与合批优化

排序之后，如何渲染这些粒子？UGUI渲染的是网格。因此，插件需要动态生成一个包含所有粒子四边形（两个三角形）的网格。这个过程每帧都可能发生，因为粒子的位置、大小、颜色都在变化。

网格重建流程：

1. 根据存活粒子数，分配或复用顶点（Vertex）和三角形索引（Triangle Index）数组。
2. 遍历排序后的粒子列表，为每个粒子计算四个顶点的最终位置（考虑粒子位置、大小、旋转）。
3. 为每个顶点设置UV坐标（用于采样纹理）、顶点颜色（取自粒子的颜色模块）。
4. 填充三角形索引，将四个顶点连成两个三角形。

合批（Batching）优化： 如果场景中有多个ParticleEffectForUGUI组件，且它们使用了完全相同的材质球（Material）和纹理（Texture），插件会尝试将它们合并批次以减少DrawCall吗？这取决于插件的具体实现。一些高级实现会跨组件进行动态合批，但这需要更复杂的管理机制（如共享材质属性块）。更常见的做法是，每个ParticleEffectForUGUI组件独立管理自己的网格和DrawCall。因此，最佳实践是：尽可能让同一个Canvas下、需要同时显示且材质相同的粒子效果，共享同一个ParticleEffectForUGUI组件下的多个ParticleSystem子发射器，而不是创建多个组件。这样可以确保它们被合并到同一个网格中，实现最优的渲染性能。

4. 核心实现细节与源码探秘

要真正掌握RenderingOrder，我们不可避免地要窥探其源码实现的核心片段（以下为基于常见实现的原理性伪代码和解释，并非直接拷贝）。

4.1 粒子数据抓取与转换

插件的核心脚本（例如UIParticleSystem）会在LateUpdate()中执行以下操作：

void LateUpdate() { if (particleSystem == null) return; // 1. 获取当前帧所有存活粒子 int aliveParticlesCount = particleSystem.GetParticles(particles); // 2. 计算每个粒子的排序键 float[] sortKeys = new float[aliveParticlesCount]; for (int i = 0; i < aliveParticlesCount; i++) { sortKeys[i] = CalculateSortingKey(particles[i]); } // 3. 根据排序键对粒子数组进行排序 // 注意：需要同步排序粒子数据数组和排序键数组 Array.Sort(sortKeys, particles, 0, aliveParticlesCount); // 4. 使用排序后的粒子数据重建网格 UpdateMesh(aliveParticlesCount); }

这里的CalculateSortingKey函数就是策略模式的应用点，根据不同的排序模式（如SortingMode.Distance）选择不同的计算方法。

4.2 动态网格更新

UpdateMesh函数是性能敏感区域：

void UpdateMesh(int count) { // 确保网格数据容器大小足够 if (vertices.Length < count * 4) { // 重新分配数组，注意预留一些空间避免频繁分配 vertices = new Vector3[count * 4 + 100]; uvs = new Vector2[count * 4 + 100]; colors = new Color32[count * 4 + 100]; triangles = new int[count * 6 + 150]; } int vertIndex = 0; int triIndex = 0; for (int i = 0; i < count; i++) { Particle particle = particles[i]; // 计算粒子的旋转、大小，并确定四个角点 // ... 此处是复杂的矩阵变换计算 ... // 填充顶点数据 vertices[vertIndex] = corner0; vertices[vertIndex+1] = corner1; vertices[vertIndex+2] = corner2; vertices[vertIndex+3] = corner3; // 填充UV（支持纹理动画） uvs[vertIndex] = particle.uv0; // ... 填充其他三个UV // 填充顶点颜色（支持Color over Lifetime） colors[vertIndex] = particle.color; // ... 填充其他三个顶点颜色 // 填充三角形索引 triangles[triIndex] = vertIndex; triangles[triIndex+1] = vertIndex+1; triangles[triIndex+2] = vertIndex+2; triangles[triIndex+3] = vertIndex+2; triangles[triIndex+4] = vertIndex+3; triangles[triIndex+5] = vertIndex; vertIndex += 4; triIndex += 6; } // 将网格数据设置给CanvasRenderer canvasRenderer.SetMesh(mesh); canvasRenderer.SetTexture(mainTexture); }

实操心得：这里有一个常见的性能陷阱——数组的频繁重分配。如果每帧粒子数量波动很大，vertices等数组就会频繁new，触发GC（垃圾回收），导致卡顿。优秀的实现会采用“缓冲池”思想：分配一个足够大的初始数组，并跟踪实际使用的长度。只有在当前数组绝对不够用时才扩容，并且扩容时不是精确分配count*4，而是按一定比例（如1.5倍）扩大，预留增长空间。在查看或自己实现类似功能时，务必关注这一点。

4.3 与UGUI渲染管线的对接

最关键的一步是如何让这个动态网格被UGUI“认出来”并正确渲染。这通常通过重写ICanvasRaycastFilter接口（虽然这里主要不是为了射线检测）以及正确设置CanvasRenderer的属性来实现。

插件组件通常会：

1. 继承自MaskableGraphic（UI基础类）或直接管理一个CanvasRenderer。
2. 在OnPopulateMesh或UpdateGeometry方法中（对于MaskableGraphic子类），填充我们上面生成的网格数据。但更常见的做法是，插件直接绕过OnPopulateMesh，因为那是为静态UI设计的。它们可能会在LateUpdate中直接调用canvasRenderer.SetMesh()。
3. 设置正确的材质。这个材质通常是一个特殊的UI粒子着色器（UI Particle Shader），它需要支持UGUI的Stencil Test（用于Mask）和混合模式（Blend Mode），同时还要能读取粒子顶点颜色和UV动画。
4. 通过设置canvasRenderer.sortingOrder或canvasRenderer.sortingLayerID，或者通过控制GameObject的Sibling Index，来影响其在Canvas中的最终绘制顺序。

5. 实战应用与性能调优指南

理解了原理，我们来看看如何在项目中实际应用并优化它。

5.1 常见使用场景与配置

1. 按钮交互特效：为按钮添加一个ParticleEffectForUGUI子物体，发射少量粒子。设置排序模式为Local Z，并确保该GameObject在Hierarchy中位于按钮Image的下方，这样粒子就会从按钮后面浮现出来，营造“光晕透出”的效果。
2. 全屏UI转场：在两个UI界面切换时，使用一个覆盖全屏的、带有ParticleEffectForUGUI的Canvas，播放星尘流动或光粒消散的动画。由于其层级最高，可以制造华丽的过渡。注意控制粒子数量（通常100-200个足矣），并使用简单的纹理。
3. 角色状态指示器：在World Space的头顶血条Canvas上，附加粒子效果来表现中毒、燃烧、增益等状态。此时排序模式应选用Distance，以确保粒子在3D空间中正确被血条或其他3D物体遮挡。
4. 滚动列表项特效：在滚动列表的每个Item上附加粒子效果，当Item滚动到视图中时播放。这里要特别注意Mask的协作。确保粒子效果所在的Canvas层级在ScrollRect的Mask范围内，并且粒子的材质支持Stencil。一个常见的坑是粒子因为合批问题跑到了Mask外面，这时需要检查材质的Stencil设置和渲染队列。

5.2 性能深度调优策略

粒子UI效果虽好，但滥用极易成为性能杀手。以下是我从多个项目中总结的调优清单：

• 控制粒子数量是王道：UI粒子不是场景特效，数量宜精不宜多。超过200个活跃粒子就需要警惕。充分利用粒子系统的Emission over Time和Bursts模块进行精细控制。
• 纹理图集（Atlas）与合批：尽可能将多个粒子效果使用的纹理合并到一张图集（Texture Atlas）中。这样，即使它们分布在不同的ParticleEffectForUGUI组件上，只要使用同一个材质球（引用同一张图集），Unity的UGUI合批器就有可能将它们合批，大幅减少DrawCall。可以使用Unity的Sprite Atlas功能或第三方工具创建图集。
• 简化着色器：使用或编写尽可能简单的UI粒子着色器。避免在片段着色器（Fragment Shader）中进行复杂的逐像素光照计算、多重纹理采样或屏幕后处理效果。标准的“顶点颜色 * 纹理 + Alpha混合”对于大多数UI粒子已经足够。
• 禁用不可见粒子：如果粒子效果所在的UI界面暂时不可见（如弹窗已关闭），一定要停止粒子发射（ParticleSystem.Stop()）并清空已有粒子（ParticleSystem.Clear()），同时禁用ParticleEffectForUGUI组件或整个GameObject。让不可见的组件继续模拟和渲染是最大的性能浪费。
• 慎用自定义排序：如前所述，自定义排序函数每帧对每个粒子执行。如果你的排序逻辑复杂，或者粒子数量成百上千，这将是CPU上的沉重负担。如果非用不可，确保函数内只做最简单的算术或逻辑比较。
• Profile工具是你的朋友：定期使用Unity的Profiler窗口，特别是Rendering区域和UI区域，观察ParticleEffectForUGUI相关的Canvas.BuildBatch和Mesh.Create等操作的耗时。如果发现某处耗时激增，就是需要优化的信号。

5.3 与UI Mask的协作疑难解答

ParticleEffectForUGUI与UI Mask的协作是其核心功能，也是最容易出问题的地方。

问题一：粒子不被Mask裁剪。

• 检查1：确保粒子效果所在的Canvas层级在Mask节点的子层级或同级（且在其后渲染）。Mask只影响其子物体。
• 检查2：确认粒子使用的Shader支持Stencil Test。ParticleEffectForUGUI通常会提供一个专用的Shader，如“UI/Particle/Additive (Maskable)”。使用这个Shader或其变体。不要使用粒子系统默认的Standard或Legacy Shader。
• 检查3：检查ParticleEffectForUGUI组件上是否有Maskable属性（如果它继承自MaskableGraphic），并确保其为true。

问题二：粒子边缘出现锯齿或闪烁。

• 原因：这通常是深度（Depth）或模板（Stencil）冲突导致的Z-fighting。在Mask边界处，粒子像素与UI像素的深度值过于接近。
• 解决：尝试微调粒子材质的渲染队列（Render Queue）。对于UI粒子，通常使用Transparent队列（3000）。你可以尝试设置为3001或2999，使其与UI的渲染队列略有错开。此外，确保粒子发射器的Simulation Space设置为Local（对于UI粒子这是最安全的），避免因世界空间坐标计算引入的精度问题。

6. 进阶技巧与自定义扩展

当你熟练使用基础功能后，可以尝试以下进阶玩法，让粒子UI更具表现力。

6.1 实现粒子与UI元素的交互遮挡

默认情况下，ParticleEffectForUGUI作为一个整体UI块，要么在所有Image上面，要么在下面。但有时我们需要更精细的控制：让粒子在某个特定Image后面，却在另一个Text前面。这可以通过“分层渲染”实现。

技巧：创建多个ParticleEffectForUGUI组件，将它们拆分成不同的GameObject，并精确地插入到Hierarchy中你希望的位置。例如：

Canvas ├── BackgroundImage ├── UIParticle_BehindText (GameObject) │ └── ParticleEffectForUGUI (组件) // 这个粒子在背景和文字之间 ├── MainText └── UIParticle_OnTop (GameObject) └── ParticleEffectForUGUI (组件) // 这个粒子在所有UI之上

通过拆分，你可以用最原始的Hierarchy顺序，实现复杂的多层粒子穿插效果。

6.2 编写自定义排序函数

假设你想实现一个效果：粒子根据其生命值（自定义流Custom Data）来排序，生命值高的显示在前面。

public class CustomSortParticle : MonoBehaviour { public UIParticleSystem uiParticle; // 引用你的UIParticleSystem组件 public ParticleSystem particleSys; void Start() { // 假设UIParticleSystem组件提供了设置自定义排序委托的接口 // 这是一个示例接口，具体名称请查看你所使用插件的API uiParticle.SetCustomSortingFunction(SortByCustomData); } private float SortByCustomData(ParticleSystem.Particle particle) { // 假设你已经在粒子系统中设置了Custom Data Stream 0 为生命值 // 你需要通过粒子系统的GetCustomParticleData方法获取数据 // 这里仅为逻辑示例 // List<Vector4> customData = new List<Vector4>(); // particleSys.GetCustomParticleData(customData, ParticleSystemCustomData.Custom1); // float lifeValue = customData[particleIndex].x; // 为了示例，我们假设生命值存储在startColor的alpha通道（这是一种常见做法） float lifeValue = particle.startColor.a; // 返回排序键：生命值越高，排序键越大，渲染越靠后（通常CanvasRenderer后渲染的在上层） // 注意：排序逻辑取决于插件内部是升序还是降序排列，可能需要取反 return -lifeValue; // 假设插件升序排列，取负值让生命值高的粒子键值更小，先渲染（在底层） } }

注意：自定义排序函数的性能开销需要严格评估。确保函数内只进行最简单的数据访问和运算。每帧对上千个粒子执行复杂计算是不可取的。

6.3 动态修改粒子层级

有时我们需要在运行时动态改变粒子效果的层级。例如，一个提示框弹出时，希望其附带的粒子效果显示在最顶层。

这可以通过修改CanvasRenderer的sortingOrder来实现。ParticleEffectForUGUI组件通常会暴露这个属性或提供一个等效的接口。

// 假设uiParticle有一个public的CanvasRenderer成员或属性 uiParticle.canvasRenderer.sortingOrder = 100; // 设置一个很高的排序顺序 // 或者，通过改变Transform的Sibling Index uiParticle.transform.SetAsLastSibling(); // 移动到同级节点的最后，从而最后渲染（在最上层）

动态修改层级在制作可复用的UI粒子预制件时非常有用，你可以写一个简单的脚本，在实例化时根据上下文自动调整其sortingOrder。

7. 排查与解决常见问题实录

即使理解了原理，在实际开发中还是会踩坑。下面是我遇到的一些典型问题及解决方法。

问题1：粒子显示为紫色（Missing Material）。

• 现象：粒子效果在Game视图中显示为紫色方块。
• 排查：这是Shader或Material丢失的典型表现。
• 解决：
  1. 检查ParticleEffectForUGUI组件上指定的Material是否有效。
  2. 检查该Material使用的Shader是否是ParticleEffectForUGUI包提供的专用UI粒子Shader（如UI/Particle/***）。使用Standard Shader或普通粒子Shader是行不通的。
  3. 如果Material是好的，检查是否有多个Canvas，粒子是否被错误地放置到了一个不渲染的Canvas上（例如，Canvas的Render Mode设置错误或Camera未赋值）。

问题2：粒子闪烁或抖动。

• 现象：粒子在屏幕上快速闪烁或位置抖动。
• 排查：
  1. Canvas缩放问题：如果Canvas是Screen Space - Camera或World Space模式，且粒子的Simulation Space是World，那么摄像机或Canvas的轻微移动/缩放都会导致粒子位置剧烈变化。确保UI粒子的Simulation Space设置为Local。
  2. 排序冲突：如果两个不同的ParticleEffectForUGUI（或与其他UI元素）具有完全相同的sortingOrder和深度值，可能会引起Z-fighting，导致闪烁。为它们设置明确的、不同的排序值。
  3. 帧率不稳定：极低的帧率可能导致粒子更新和网格重建不同步。优化整体性能。

问题3：DrawCall异常升高。

• 现象：Profiler显示UI渲染的DrawCall数量远高于预期。
• 排查：
  1. 材质差异：每个独特的Material（即使纹理相同，但材质球实例不同）都会打断合批。确保所有希望合批的粒子效果共享同一个Material实例。
  2. 纹理差异：即使使用同一个Material，如果粒子使用了不同的纹理（Texture），同样会打断合批。使用纹理图集是唯一解决方案。
  3. Canvas分割：多个Canvas之间无法合批。检查是否无意中创建了过多的小Canvas。尽量将相关的UI元素（包括粒子效果）组织在同一个Canvas下。
  4. Overdraw：大量半透明粒子叠加会导致严重的Overdraw（过度绘制），即使DrawCall不高，也会造成填充率瓶颈，在移动设备上表现为帧率下降。解决方法是减少粒子数量、使用更简单的粒子形状、或者让粒子在不需要时尽快消失。

问题4：粒子不受RectMask2D裁剪。

• 现象：粒子跑到了RectMask2D定义的矩形区域之外。
• 排查：这是最经典的问题。RectMask2D使用Stencil Buffer进行裁剪。
• 解决：
  1. 确认粒子材质启用了Stencil Test。在材质的Shader中，需要有类似Stencil { Ref 1 Comp Equal Pass Keep }的指令。
  2. 确认ParticleEffectForUGUI组件所在的层级在RectMask2D节点的子层级。
  3. 如果使用了自定义Shader，确保Stencil逻辑正确。最稳妥的方法是直接使用插件提供的标准Maskable Shader。

处理这些问题的方法论是：先定位问题属于渲染管线中的哪个环节（是数据问题、排序问题、合批问题还是Shader问题），然后利用Unity的Frame Debugger工具逐步查看绘制命令，结合Profiler进行性能分析，最终锁定并实施解决方案。这个过程本身，就是对Unity UI渲染机制一次极好的深度学习。