企业官网建设流程全解析

1. 先定位：你的粒子特效到底是哪种“显示不全”

做Unity这些年，粒子特效“打包后和编辑器里不一样”是我见过最磨人的问题之一。美术在编辑器里把火光、雪花、技能光效调整得漂漂亮亮，你点了一下Build，在真机上一跑——粒子要么直接消失，要么飞到一半被切掉，要么颜色发灰发黑，要么闪烁得像接触不良。这不是个别现象，我在做数字孪生项目、展厅互动程序、乃至车机仪表盘开发时都踩过同样的坑。

最麻烦的是，这类问题不报错。脚本空引用会给你红色的Log，模型加载失败会变成紫色材质，但粒子显示不全大概率没有任何提示，你只能对着真机屏幕干瞪眼。这篇文章我打算把近几年排查过的“粒子特效显示不全”问题做个归类整理，给出一套从现象定位到最终修复的完整排查路径。不管你是Unity开发者、技术美术，还是独立开发者在做自己的小游戏，都应该能从里面找到对应的解法。

动手排查之前，先别急着改参数，第一步是要搞清楚：你说的“显示不全”，到底是哪一种？粒子特效显示不全这个说法太笼统了，如果不先界定清楚，你很可能在错误的方向上浪费一整天。

1.1 四种典型现象的快速对照

我把实际项目里遇到过的“显示不全”分成四类，每种对应的根因和排查方向完全不同：

在四个类型中，我只显示一部分是最容易让新手懵掉的。因为粒子系统明明在运行，每个粒子的位置、速度、生命周期都没问题，但从某个角度看去，粒子会像撞到一面无形的墙一样被齐刷刷地切断。这个问题和“Unity Renderer的包围盒”直接相关，后面第3章会详细说。

1.2 编辑器复现 vs 真机复现，谁先谁后

第二步是做一个关键判断：这个问题在Unity编辑器里能不能复现？

如果编辑器里就能复现，那大概率不是打包导致的，问题出在粒子参数、场景光照或脚本逻辑上。比如你把粒子的Start Speed调到了100，但场景里摄像机跟随的路径正好让粒子飞出了相机视野，这属于场景布置问题；再比如粒子的Render Mode设置为Mesh，但Mesh没有赋值，编辑器场景里会报错但也有可能直接不渲染。

如果编辑器里一切正常，只有打包后在真机上才出问题，那重点检查这几类因素：

• 平台相关的Shader变体裁剪
• 目标平台的图形API特性差异
• 纹理压缩格式的变化
• 资源加载或AssetBundle的依赖缺失

这两类问题的排查思路是完全不同的。前者是“功能性问题”，后者是“平台差异性问题”。我见过有人为了排查一个编辑器里就存在的粒子缺失问题，反复打包了十几次，最后发现只是RenderMode下拖尾的Material没赋值——这种低级错误在编辑器里多看一眼Scene视图就能发现。

1.3 单个粒子异常 vs 全局粒子异常，影响范围区分

还有一个高效的定位维度：是场景里所有粒子系统的共同问题，还是只有某一个粒子系统出问题？

如果是全体粒子System都异常，说明问题出在工程宏观层面，比如色彩空间被改成了Linear而Shader没有适配、后处理Volume里挂了不兼容的Bloom、整个材质库引用的Shader都不见了。这类全局问题优先检查工程设置。

如果只有某一个粒子系统异常，把注意力集中在这个粒子自身的配置上：材质的Shader是否被正确引用、粒子模块里是否用了特殊功能（如Custom Vertex Streams）、这个Prefab是否被打进了AssetBundle、在Bundle模式下资源依赖是否完整。尤其是用AssetBundle做热更新时，粒子Prefab引用的Shader如果没有被打进依赖包，真机上就会出现“粒子发射了但渲染不出来的”诡异现象。

2. Shader变体丢失：打包后粒子不渲染的头号元凶

先说出镜率最高的一个原因：Shader变体丢失。我参与过的项目里，一大半粒子打包后不显示、材质变粉、渲染出来是纯色方块，最后都追到了这里。

2.1 为什么编辑器里正常，打包后就紫屏或空白

Shader在Unity里不是一个简单的一对一关系，一个Shader文件可以包含多个SubShader，每个SubShader里又有多个Pass，再加上各种#pragma multi_compile或#pragma shader_feature声明的宏开关——这些排列组合起来就是“Shader变体（Shader Variant）”。

为了控制包体大小，Unity在打包时会对Shader变体进行裁剪。它只保留场景中实际引用到的、以及预设好要包含的变体，其余的一律丢掉。编辑器环境下资源加载路径完整，很多宏组合在编辑器里能正常编译出来，但打包后缺少对应变体，材质就会失效。

对粒子系统来说，这个坑尤其容易踩。因为粒子Shader往往是走透明混合的，还有HDR颜色支持、软粒子、扭曲、溶解、自定义顶点流（Custom Vertex Streams）等特性，每开一个特性就多出好几个变体。如果某个变体没有被场景中的任何物体引用，在增量打包时很容易被Unity的Shader裁剪机制判定为“无用数据”而剔除。结果就是：粒子系统照常发射，但渲染出来是空的。

2.2 打包前先查这3个地方

想快速确认是不是Shader变体的问题，打开Build出的包或直接看Build Report，检查这3个地方：

第一，材质球上引用的Shader名称。在编辑器里选中出问题的粒子材质，看Inspector顶部Shader下拉框里选中的是哪个。如果你在工程里看到了Shader文件存在，但打包后无法使用，多半就是变体没有进包。

第二，着色器的Keyword状态。粒子材质Inspector下方会有一排Shader Keywords的勾选项，比如Enable Instancing、SOFTPARTICLES_ON、FOG_LINEAR等。在编辑器里勾选了这些特性，但打包时对应的Keyword变体被裁剪，表现就是粒子显示不完整——比如软粒子失效了，粒子会和场景物体生硬穿插；雾效开了但Fog变体没了，粒子颜色不对。

第三，Always Included Shaders列表是否包含了粒子所用Shader。打开Player Settings → Graphics，在Always Included Shaders面板里检查。这个列表里的Shader会被无条件打进包内，不受变体裁剪影响。

2.3 Always Included Shaders：加多了包大，加少了出事

Always Included Shaders是解决变体丢失最粗暴但最有效的方案。但这里我要说一句：无脑把所有Shader往这个列表里塞，是不可取的。

我在一个项目里看到过有人为了图省事，把整个项目用到的几百个Shader全部勾进了Always Included列表，包体直接多出好几十兆，而且加载Shader的时间明显变长，首帧卡顿问题随之而来。正确的做法是：

• 只把粒子系统确实用到的核心Shader加进去，比如Particle/Standard Unlit、Legacy Shaders/Particles/Additive这类项目里的高频粒子Shader。
• 其余Shader用ShaderVariantCollection收集器来精准管理。右键点击Assets，选择Create → ShaderVariantCollection，然后在Window → Rendering → Shader Variant Collection里手动添加或通过Build Report导入变体。
• 如果项目用了URP/HDRP，注意内置管线的粒子Shader和可编程管线的Shader不能混用。从内置管线升级到URP后，如果粒子材质还挂着内置的Particles/Standard Unlit，打包出来依然会很诡异。

2.4 一个脚本快速收集粒子Shader引用

当你面对一个大型项目，不知道哪些Shader被粒子系统引用时，手动一个个找确实费劲。这里分享一个我在项目中用来做打包前检查的编辑器脚本，放到Editor目录下就能用：

using UnityEngine; using UnityEditor; using System.Collections.Generic; public class ParticleShaderCollector : EditorWindow { [MenuItem("Tools/Particle/收集所有粒子系统使用的Shader")] static void CollectParticleShaders() { var result = new Dictionary<Shader, int>(); var particleSystems = FindObjectsOfType<ParticleSystem>(true); foreach (var ps in particleSystems) { var renderer = ps.GetComponent<ParticleSystemRenderer>(); if (renderer == null) continue; var mats = renderer.sharedMaterials; foreach (var mat in mats) { if (mat != null && mat.shader != null) { if (result.ContainsKey(mat.shader)) result[mat.shader]++; else result[mat.shader] = 1; } } } Debug.Log("===== 粒子Shader引用统计 ====="); foreach (var pair in result) { Debug.Log($"{pair.Value}次 -> {pair.Key.name}"); } } }

运行后会输出当前场景中所有粒子系统用到的Shader及引用次数。拿到结果后，手动把这些Shader加入Always Included Shaders或变体收集器，很大概率就能解决打包后粒子不渲染的问题。这个脚本还可以扩展成遍历某个目录下所有Prefab的版本，替换FindObjectsOfType改为从指定路径LoadAllPrefab即可，适合在打包CI流程里自动执行。

3. 包围盒被裁剪：粒子“飞一半消失”的真正原因

如果说Shader变体丢失是“粒子完全不显示”的元凶，那“粒子只显示一半、飞到一半被切断”的幕后黑手，大概率是包围盒（Bounds）计算问题。这个词在热搜里也出现了，说明不少人在排查时都想到了Renderer的包围盒，但未必弄清楚了它的工作机制。

3.1 看一次Bounds：打开Show Bounds一分钟定位

先说操作，再讲原理。选中出问题的ParticleSystem，在Inspector中找到Renderer模块，勾选最下面的Show Bounds选项。这时候Scene视图里会出现一个半透明的白色长方体线框，那东西就是Unity为该粒子系统计算出的包围盒。

然后你播放一下粒子效果，观察粒子飞行的范围。如果粒子飞出了白色线框，问题就100%定位了：粒子的实际渲染范围超出了包围盒，超出的部分在渲染时被视锥裁剪吃掉了。你看到的“显示不全”，本质上是粒子被包围盒切了一刀。

这个包围盒是Unity自动计算的，编辑器模式下会根据粒子系统的各项参数（Start Speed、Size、Gravity Modifier等）预估粒子的活动范围。问题在于：这个预估在很多特殊情况下是不准的，尤其是打包后帧率变化、粒子插值精度变化时，误差会被放大。

3.2 为什么Shader做顶点偏移、高速粒子更容易中招

Unity对粒子系统包围盒的计算基于CPU端的粒子模拟数据。你设置的Start Lifetime、Start Speed、Size、Velocity Over Lifetime曲线，Unity都能拿来预估粒子能飞多远。但有两种情况，CPU端完全无法预知粒子的最终位置。

第一种是Shader在顶点阶段对粒子位置做了偏移。比如你在Shader里写了一段代码，让粒子在GPU端做额外的位移、波动、扭曲，这些操作发生在渲染管线里，CPU算包围盒的时候根本看不见。结果就是粒子实际渲染位置在包围盒之外，被活活裁剪掉。

第二种是粒子速度极快、生命周期较长。比如模拟子弹拖尾、流星划过的特效，粒子以极高的速度飞行，如果Bounds预估的精度不够，某个时刻粒子就会超出边界。这种问题在编辑器低帧率下可能不明显，但打包后帧率提升，粒子每帧插值步长变化，边界就越容易突破。

3.3 Custom Bounds手动扩大边界 + 脚本写法

修复方式很简单：在Renderer模块中勾选Custom Bounds，手动输入一个足够大的包围盒范围。不要担心把Bounds设大了会影响性能——包围盒大一点只意味着视锥裁剪没那么准，并不会增加渲染开销，代价最多是粒子在视野外时也会被发送到GPU，但对于粒子特效来说，这个代价几乎可以忽略。

如果很多粒子系统都需要修，或者你想在代码里统一处理，可以写一个编辑器批处理脚本：

using UnityEditor; using UnityEngine; public class ParticleBoundsFixer { [MenuItem("Tools/Particle/为所有粒子系统设置自定义包围盒")] public static void SetCustomBoundsForAll() { var allParticles = Object.FindObjectsOfType<ParticleSystem>(true); foreach (var ps in allParticles) { var renderer = ps.GetComponent<ParticleSystemRenderer>(); if (renderer == null) continue; // 扩大边界，具体数值可根据项目的粒子飞行距离调整 renderer.bounds = new Bounds(Vector3.zero, Vector3.one * 200f); EditorUtility.SetDirty(renderer); } AssetDatabase.SaveAssets(); Debug.Log($"已为 {allParticles.Length} 个粒子系统设置自定义包围盒"); } }

注意这个方法会覆盖所有粒子的Bounds设置，你需要评估项目里粒子飞行距离的合理范围，设置一个全局可接受的兜底值。更精细的做法是让美术在预制体面板里按实际需要逐个配置Custom Bounds。

3.4 边界问题相关：相机远裁剪面、视野外裁剪的干扰

还有一个容易被误判的“显示一半”情况：粒子没有超出包围盒，但超出了相机的Far Clip Plane（远裁剪面）。当粒子系统里某个粒子的Z轴距离超过相机Far值，即使粒子本身在场景中，也会被相机裁剪掉。尤其在数字孪生项目中，场景尺度往往很大，如果相机Far设为100，而粒子飞行距离达到了150，那飞出去的部分就会消失。

这种问题很好排查：真机调试时移动摄像机或拉远视角，如果粒子又出现了，说明不是粒子本身的问题，而是相机裁剪范围不够。打开相机组件，把Far Clip Plane调大，或者确保粒子特效与相机的距离在设计范围之内。另外，粒子系统有Culling Mode选项（Renderer模块 → Culling Mode），默认是Automatic，可以改成Always Animate，避免粒子在距离相机较远时被Unity的“自动休眠”机制跳过渲染。

4. 合批、图集、纹理压缩：三个“显示不全”的隐形帮凶

Shader变体和包围盒是“大问题”，但现实中很多粒子的显示不全，是合批、图集、纹理压缩这类细节问题叠加出来的。单个看都不致命，但组合在一起，非常难排查。

4.1 动态合批导致半透明粒子排序错乱

粒子特效大多是半透明渲染的。半透明物体的渲染顺序在Unity里是按距离排序的——离相机越远越先渲染，越近越后渲染。这保证了远处的半透明物体会被近处的正确覆盖。

但动态合批（Dynamic Batching）介入后，排序基准会发生变化。合批会把多个小网格拼成一个更大的网格一次性提交，当粒子系统参与合批后，排序依据可能从“单个粒子的位置”变成了“合批对象的中心点”。一旦发生这种情况，半透明粒子的前后遮挡关系就会错乱，表现就是粒子被场景中某个物体“吃掉”一部分，或者粒子之间互相遮挡出现闪烁。

解决办法是在不必要的地方关掉动态合批。Player Settings → Player → Other Settings → Dynamic Batching，如果项目对粒子渲染质量要求高，可以取消勾选；或者通过为粒子材质开启GPU Instancing来替代合批，GPU Instancing对大数量粒子的渲染性能更好，而且不会引入排序错乱。

4.2 纹理压缩后边缘发黑、透明缺口

粒子纹理在编辑器里显示正常，但打包到Android后边缘出现黑边、透明区域出现噪点或缺口，这是移动端纹理压缩格式导致的。

移动端为了节省显存，默认会把纹理压缩成ASTC（Android）或PVRTC（iOS）等格式。对于包含精细Alpha边缘（比如烟雾、火焰的蓬松边缘）的粒子贴图，有损压缩很容易把Alpha边缘压坏，视觉上就像粒子形状缺了一块。

推荐做法是：在粒子贴图的Import Settings中，把Android平台的分辨率Formats设为ASTC 6x6或更高品质（数值越小质量越高，但体积越大），iOS则根据设备选择ASTC或PVRTC。如果粒子纹理对透明度要求极其苛刻，还可以勾选Compress Assets选项下的“Use Crunch Compression”并设置较高质量，或干脆取消纹理压缩，代价是内存占用上升。拿到真机上对比之后再决定。

4.3 图集里的Sprite引用在打包时被剔除

还有一些“显示不全”是资源依赖层面的。粒子系统如果使用Sprite作为粒子的渲染贴图（Render Mode → Sprite），而这个Sprite来自一张图集（Atlas），需要注意图集当前是否被打包进了目标AssetBundle。

在AssetBundle工作流中，如果一个粒子Prefab依赖一个Sprite，但AssetBundle打包时没有正确处理依赖关系（比如图集没有被标记为该Bundle的依赖），真机上加载时Sprite引用是空的，粒子就会发射但显示不出任何内容。这种问题Log里一般会有警告，但很多团队不会盯着日志看。

解决办法：使用SpriteAtlas时，把粒子Prefab和它依赖的SpriteAtlas标记在同一个或正确的依赖Bundle中，并在构建时开启“Include in Build”。同时建议在粒子Prefab的材质上直接引用图集里的Sprite，而不是让粒子系统动态去图集里查找，降低依赖解析的复杂度。

5. 平台专项差异：移动端、WebGL、微信小游戏的坑

同一套工程，换一个平台打包，粒子表现就可能完全不同。这不是玄学，而是平台底层的图形API、硬件能力、资源格式支持差异在起作用。这几年我陆续对接过Android、iOS、PC、WebGL和微信小游戏平台，每个平台都有自己的一套“粒子特效显示不全”的典型剧本。

5.1 图形API差异：OpenGL ES、Metal、Vulkan谁更挑Shader

Android平台支持OpenGL ES 2.0、OpenGL ES 3.0和Vulkan，iOS只有Metal，PC可以是OpenGL Core、D3D11或D3D12。同一个Shader在不同图形API上的编译结果可能会有差异。

最常见的坑是OpenGL ES 2.0不支持某些高级Shader特性。比如标准的Legacy Shaders/Particles/Additive在GLES 2.0上正常工作，但如果你用了需要法线、切线、顶点色自定义流的粒子Shader，GLES 2.0就会罢工。现在Unity新版本默认已经不支持GLES 2.0了，但如果你维护的是老项目，需要注意Player Settings里是否还勾选了GLES 2.0。

Vulkan作为Android上主推的图形API，整体兼容性不错，但个别设备的驱动实现存在问题，半透明混合（Alpha Blend）可能出现不一致。如果团队测试设备有限，建议在Player Settings的Graphics API列表里把OpenGL ES 3.0排在Vulkan前面，先保持兼容性，再考虑性能优化。

iOS的Metal是强制使用的，基本不存在API选择问题，但粒子Shader如果写了#ifdef SHADER_API_MOBILE分支代码，要注意Metal端的实际编译行为与GLES上是否一致，哪怕是内置Shader也可能存在细微差异。

5.2 WebGL与微信小游戏：Draw Call、Shader编译与首帧问题

WebGL平台和微信小游戏打包后，粒子显示不全往往不是“Shader丢失”，而是性能与兼容性双重夹击下的表现。

先说Draw Call。WebGL和微信小游戏环境下，Draw Call对帧率的影响比独立平台更明显。如果粒子系统发射数量大、材质多，一个特效就产生几百个Draw Call，帧率会瞬间掉到个位数，视觉效果上就是“粒子卡住不动”或“粒子只能显示前几帧就再也刷新不出来”。这种问题不是渲染错误，而是性能瓶颈。优化手段包括：尽量用GPU Instancing，减少粒子材质数量（一个特效最多用2-3个材质），降低粒子发射峰值数量。

再说Shader编译。WebGL平台在运行时首次遇到一个Shader时需要进行GLSL编译，这个过程可能耗时几百毫秒甚至更久。如果在粒子首次发射时才触发编译，会导致粒子延迟几帧才出现，看起来就像是“粒子显示不全”——有一部分粒子没有在预期时间渲染出来。解决方案是在场景加载预编译Shader变体，Unity的ShaderVariantCollection在这里也能派上用场。

微信小游戏还要注意自定义Shader的支持度。微信小游戏运行环境基于WebGL，但引擎层做了裁剪，部分自定义Shader特性可能不被支持。如果你在小游戏平台用了比较复杂的顶点变形Shader，一定要在真机预览环境里尽早验证。另外微信小游戏对纹理格式也有要求，部分压缩格式（例如ETC2在某些低端安卓WebView上）不支持，粒子贴图需要准备兜底格式。还有一个常被问到的坑：Unity发布WebGL时AssetBundle使用IDBFS写入失败会导致资源加载异常，粒子特效如果依赖动态加载的Ab，资源没加载出来自然没法渲染。这种问题要重点排查WebGL的IndexedDB空间是否充足、浏览器是否禁用了本地存储。

5.3 色彩空间Linear/Gamma导致整体偏色

最后说一个容易被误解为“显示不全”的问题：打包后粒子整体颜色变暗或变亮。这种偏色现象在移动端尤其常见，根源是色彩空间（Color Space）设置不统一。

在Player Settings的Other Settings里，Color Space可选Gamma或Linear。线性空间（Linear）的渲染结果物理上更准确，但如果在Linear项目里用了没有做Gamma校正的粒子Shader，或者贴图没有勾选sRGB（Texture Import Settings里的SRGB选项），粒子颜色就会看起来偏灰或偏暗。

排查方法很简单：把同一台真机上编辑器截图和粒子所在的场景截图放在一起对比色值。如果只是整体变暗而不是局部缺失，优先检查色彩空间和贴图的sRGB设置。粒子贴图如果是颜色贴图，应勾选sRGB；如果是数据贴图（比如用于控制粒子大小、速度的噪声图），一定不能勾选sRGB，否则数据经过Gamma校正后会失真。

6. 真机排查流程：五步定位法实操

前面几章讲的是“原因”，这一章讲“方法论”。当你遇到一个粒子显示不全的问题，又完全不知道是哪种原因时，按这套流程走，能系统地缩小范围。

6.1 第一步：本地强制切到目标图形API

很多人上来就直接Build一次真机包，花十分钟打包，再花五分钟安装，结果发现问题没解决，又得改代码重打包，效率极低。第一步应该先在编辑器里模拟目标平台的图形API。

在Player Settings里切换当前平台为Android或iOS，然后在Graphics API列表里把目标API（如OpenGL ES 3.0或Vulkan）设为唯一选项，取消勾选Auto Graphics API。然后直接在编辑器里运行，看粒子是否复现问题。很多图形API相关的问题能在这个环节复现出来，不用打包就能确认方向。

如果编辑器里APl切换后没问题，再进入真机流程；如果编辑器里就已经出问题，那恭喜你，省了一次打包时间，直接用Frame Debugger分析即可。

6.2 第二步：清理缓存、看Build Report

很多“只有打包后才出现”的粒子问题，其实是增量构建缓存导致的。Unity的增量构建系统会复重用过的资源包，如果某个Shader或材质在上一次构建中被裁剪了，这次勾选时可能没被重新收集。所以碰到诡异问题，先做一次 Clean Build：菜单Build → Clean Build，或者手动删除Library目录下的BuildCache、ArtifactCache等相关缓存再打包。

打包完成后，打开生成的Build Report（在Console窗口右侧的下拉菜单里点Open Build Report），在Shader Information面板里能看到所有被打进包内的Shader和变体列表。重点检索粒子用到的Shader，确认目标变体是否在列表中。这一步能直接确认前面第2章说的Shader变体丢失问题。

6.3 第三步：用Frame Debugger逐帧检查粒子Draw Call

如果Shader和Build Report都正常，问题还在，打开Frame Debugger（Window → Analysis → Frame Debugger）逐帧定位。

Frame Debugger是Unity内置的逐Draw Call调试工具。点击播放并让粒子特效运行，在Frame Debugger的Draw Call列表中找到粒子渲染对应的那一条（通常是ParticleSystemRenderer发起的Draw），点击后右侧会显示当前Draw Call使用的Shader、材质、网格、以及裁剪结果。

这里有三个关键检查点：

• 看Shader名称和材质属性面板中的纹理，确认不是空的或错误的引用
• 看“Why the draw call was culled”或裁剪状态，确认粒子没有被包围盒或视锥剔除
• 看GPU Instancing状态，确认是否因为合批规则异常导致粒子网格没有正确上传

如果你看到Draw Call存在但渲染结果为“Nothing”，问题大概率出在材质或GPU端；如果Draw Call直接被标记为“Culled”，那就是包围盒或视锥问题。这个工具能帮你把问题从“猜”变成“看”。

6.4 第四步：真机录屏、抓Log、查资源加载

编辑器里查完一切正常，还是得上真机验证。真机上的表现往往和编辑器不同，因为GPU驱动、显存容量、API实现都不一样。

接入Unity的Logger，或者用Android的Logcat工具（菜单Window → General → Console，开启Logcat窗口），把真机运行时的Log导出来。重点看三类输出：Shader编译错误（Shader error in...），纹理加载失败（Texture...could not be loaded），以及AssetBundle加载错误。很多时候粒子的“显示不全”会在Log里留下蛛丝马迹，只是你之前没看。

如果log里没有任何错误，就用手机录屏或截帧工具（如RenderDoc或Arm Performance Studio）抓真机渲染帧，和编辑器渲染帧做对比。看差异出现在哪一步：是粒子没有提交Draw Call，还是提交了但被裁剪，还是提交了但渲染结果错误。这一步能彻底排除“代码逻辑错误”和“渲染平台差异”的边界。

6.5 第五步：二分法禁用粒子模块

如果以上步骤都查完了还没有定位，说明问题可能隐藏在粒子系统某个具体模块里。粒子系统的Inspector上有十几个Module：Emission、Shape、Velocity over Lifetime、Color over Lifetime、Size over Lifetime、Noise、Collision、Trails、Lights、Mesh Emitter等。

用二分法逐个排查：先禁用粒子系统一半的模块，看问题是否消失；如果消失，说明问题在被禁用的模块里；然后逐步缩小范围。这个方法虽然笨，但非常有效。我在实际项目中用这个方法定位过两个极其隐蔽的问题：

一个是粒子系统的Collision模块。在编辑器里碰撞正常，但打包后真机的物理帧率与编辑器不同，粒子碰撞的结算结果差异导致粒子被卡在一个不显示的位置。禁用Collision模块后粒子恢复显示。

另一个是Trails模块。拖尾材质在移动端的Shader变体被打包时裁剪了一部分，导致拖尾显示不全，而粒子本身是正常的。禁用Trails后问题消失，最终通过把拖尾Shader加入Always Included列表解决。

7. 常见问题速查表

把前面几章的内容整理成一张速查表，方便你在下次遇到问题时直接对照：

提示：如果项目里同时出现了多种现象（例如一个特效既有粒子不渲染、又有边缘发黑），优先按顺序处理：先解决Shader变体问题，再处理包围盒，最后压缩和合批。Shader问题会掩盖其他问题，Shader恢复后很多现象会自动消失。

写在最后：一个老开发的经验清单

分享一个我自己的习惯。带项目时，我会在每次打包前的检查清单里固定写三条和粒子相关的事项：第一，所有粒子特效的Shader必须确认已在变体收集器或Always Included列表里；第二，所有Shader中做了顶点偏移的粒子，必须主动设置Custom Bounds；第三，所有粒子纹理在移动端构建前，必须在真机上检查一次Alpha边缘是否可接受。这几分钟检查能省掉后面一整周的排坑时间。

另外，如果你在排查过程中试了很多方法都解决不了，试着把问题抛给同事或者到技术社区搜索类似关键词。粒子显示不全这个问题，大概率不是只有你一个人遇到过，很多情况下你搜索到的某个帖子里的细节——哪怕是一个评论——就能帮你跳出思维定式。我在这篇文章里写下的每一条，都是实际项目中踩过的坑，也希望你下次碰到粒子特效显示不全时，能比我当年少走几个弯路。