Unity静态合批深度解析：原理、配置、避坑与性能优化实战

静态合批这个词在 Unity 圈子里被提得太多了，多到很多人把它当成一个“勾一下就好”的开关，结果项目一做大，Draw Call 没降下来，内存反而先炸了。我见过不少团队在优化评审会上拍着胸脯说“静态合批已经开了”，可真把 Frame Debugger 拉出来一看，合批后的批次数量跟想象中完全对不上，甚至有些物件压根没进批次。这篇就围绕静态合批这一件事，把它到底是什么、为什么能省、什么情况下会翻车、怎么落地配置、出了问题怎么排查，从头到尾捋一遍。不管你是刚接手渲染优化的新手，还是已经调过几轮性能的老手，应该都能从里面找到能直接抄作业的部分。

1. 静态合批到底在合什么：先搞懂它的底层逻辑

1.1 从一次 Draw Call 的成本说起

要理解静态合批，得先明白 Unity 渲染时一个物体从“在场景里”到“出现在屏幕上”中间发生了什么。CPU 端每渲染一个物体，大致要做这些事：检查这个物体是否在相机视锥体内、准备它的材质属性、把变换矩阵塞进常量缓冲区、然后向图形 API 提交一次绘制命令。这一次提交就是一次 Draw Call。Draw Call 本身的开销在桌面端看起来不算大，一次可能就几十微秒，但架不住数量多。场景里几百上千个物件，每个都单独提交，CPU 光在提交命令上就能耗掉好几毫秒，主线程直接被拖住，帧率自然上不去。

静态合批的核心思路非常朴素：既然每次提交都要走一遍完整流程，那能不能把多个使用相同材质的物体，提前合并成一个大网格，让它们共用一次提交？答案是能，而且因为“静态”这个前提，合并可以放在构建期或者场景加载期做，运行时几乎零成本。这里的“静态”指的是物体在整个生命周期内不会发生位移、旋转、缩放变化——位置固定、不参与动画、不会被物理系统推动。满足这个条件的物体，它们的顶点数据可以被烘焙到世界空间，拼成一个大顶点缓冲区，渲染时一次提交搞定。

这个“提前合并”带来的收益是双重的。第一，Draw Call 数量直接下降，CPU 提交开销减少；第二，因为合并后的网格共用材质和纹理，状态切换也少了，GPU 端的状态设置开销同样降低。但代价也很明确：合并后的网格会常驻内存，而且因为顶点被烘焙到世界空间，同一个网格实例被多次摆放时无法复用顶点数据，内存占用会随摆放数量线性增长。这就是为什么静态合批被叫做“免费午餐”却又不是真的免费——它用内存换 CPU 时间，划不划算取决于你的场景构成。

1.2 静态合批与动态合批、GPU Instancing 的边界

很多人把静态合批和动态合批混为一谈，其实两者的适用场景完全不同。动态合批面向的是会动的物体，它在运行时每帧把使用相同材质的顶点变换到世界空间再合并，顶点数有严格上限（默认 300 个顶点、900 个顶点属性索引），超过就合不了。静态合批没有这个顶点上限，因为它是在加载期一次性烘焙的，理论上可以合并非常大的网格，代价是内存。所以判断标准很简单：物体会不会动？不会动就走静态合批，会动才考虑动态合批或 GPU Instancing。

GPU Instancing 则是另一条路，它不合并网格，而是把同一个网格的多个实例的变换数据打包成一个数组一次性提交，适合大量重复物体（比如草地、树木、子弹）。它和静态合批可以共存，但要注意优先级：Unity 会优先尝试静态合批，然后是 GPU Instancing，最后才是动态合批。如果你的场景里既有大量重复的静态树木，又有会动的角色，那静态树木走静态合批、角色走骨骼动画加动态合批或 Instancing，各走各的路，互不干扰。

这里有个容易被忽略的点：静态合批合并的是“使用相同材质的物体”。材质不同，哪怕 shader 一样，只要材质实例不同，就合不到一起。所以真正决定合批效果的不是物体数量，而是材质种类。一个场景里如果有二十种材质，那静态合批最多也就把物体分成二十批，材质种类越多，合批收益越被稀释。这也是为什么优化时经常要先做材质合并——把能共用一张图集的贴图打到一起，减少材质种类，静态合批才有发挥空间。

1.3 为什么“静态”这个前提如此关键

静态合批的“静态”不是随便贴的标签，它直接决定了合批数据能不能被烘焙。Unity 在构建或场景加载时，会遍历所有标记为 Static 的物体，读取它们的 Mesh、变换矩阵、材质信息，把顶点从模型空间变换到世界空间，然后按材质分组拼成大网格。这个过程一旦完成，运行时这些物体的变换就被“锁死”在烘焙数据里了。如果你在运行时移动了一个标记为静态的物体，它的渲染位置不会跟着变——因为它渲染的是烘焙后的世界空间顶点，而不是实时变换后的顶点。这就是为什么静态物体绝对不能参与动画、不能被脚本改位置，否则会出现“物体动了但画面没动”或者“画面错位”的诡异现象。

这个特性也解释了静态合批的内存代价。因为顶点被烘焙到世界空间，每个摆放实例都有一份独立的顶点数据，无法像 GPU Instancing 那样共享一份网格数据加多个变换矩阵。假设一个网格有 5000 个顶点，你在场景里摆了 100 个，静态合批后就是 50 万个顶点的数据常驻内存。如果这个网格本来可以靠 Instancing 共享，那静态合批反而让内存翻了几十倍。所以判断要不要用静态合批，不能只看 Draw Call，还得算内存账。

2. 开启静态合批的正确姿势与参数取舍

2.1 项目设置里的那个开关：Player Settings 配置详解

静态合批的总开关在 Player Settings 的 Rendering 部分，具体路径是 Edit > Project Settings > Player > Other Settings > Rendering，里面有一个 Static Batching 复选框。这个开关默认是关闭的，需要手动勾上。勾上之后，Unity 才会在构建时对标记为 Static 的物体执行合批烘焙。这里有个坑：这个设置是项目级的，改了之后需要重新构建才生效，在编辑器里点 Play 测试时，合批行为跟构建后可能不完全一致，所以性能验证一定要用真机或构建包，别在编辑器里看个大概就下结论。

除了总开关，还有一个容易被忽略的相关设置：Graphics Settings 里的 Shader Stripping 和材质变体收集。静态合批本身不直接依赖这些，但如果你的 shader 变体被过度剥离，合批后的材质可能找不到正确的变体，导致渲染异常或回退到默认 shader。所以做合批优化时，建议先把 shader 变体收集跑一遍，确保合批用到的材质变体都在。

另外，Unity 版本差异也要注意。较新的版本在 Static Batching 旁边可能还有“Static Batching 的批处理阈值”之类的细化选项，不同版本命名和位置略有出入。我的建议是：升级引擎大版本后，重新检查一遍这个开关的状态，因为项目设置迁移偶尔会丢配置，尤其是从旧版本升上来的时候。

2.2 物体标记 Static 的粒度控制

光开总开关不够，物体本身必须标记为 Static 才会被纳入合批。标记方式有两种：在 Inspector 面板右上角勾选 Static 复选框，或者在代码里设置 GameObject.isStatic = true。但 Static 复选框展开后其实是一组子标记：Contribute GI、Occluder Static、Occludee Static、Batching Static、Navigation Static、Reflection Probe Static 等等。真正跟静态合批直接相关的是 Batching Static 这一项，其他几项分别服务于光照贴图、遮挡剔除、导航烘焙等系统。

这里就是第一个大坑：很多人图省事直接勾最上面的总 Static，结果把所有子项都打开了，包括 Contribute GI。如果你的场景没做光照贴图烘焙，或者这个物体根本不需要参与 GI，那勾上 Contribute GI 只会增加烘焙负担，甚至在某些配置下引发警告。正确的做法是按需勾选：只做合批的物体，勾 Batching Static 就够了；需要参与遮挡剔除的，再加 Occludee Static；需要烘焙光照的，才勾 Contribute GI。粒度控制得越细，后续排查问题越容易定位。

还有一个实操细节：标记为 Static 的物体，在 Hierarchy 里图标会变成灰色，这是正常现象。但如果你在运行时通过代码动态生成物体并设置 isStatic = true，要注意这个设置必须在物体被渲染之前完成，而且动态生成的静态物体不会自动进入已烘焙的合批数据——静态合批的烘焙发生在场景加载时，运行时新加的静态物体需要手动调用 StaticBatchingUtility.Combine 才能合并。这一点后面会专门讲。

2.3 材质与 Shader 的前置整理

前面说过，静态合批按材质分组，材质种类越少合批效果越好。所以在开启合批之前，先做一轮材质整理是值得的。具体做法是：把场景里用到的贴图尽量打到图集里，让多个物体共用同一个材质；检查有没有因为颜色微调而复制出来的材质实例，能合并的合并；确认 shader 的变体没有因为关键字不同而分裂成多个变体，导致本可以共用的材质被拆开。

举个常见的例子：场景里有一堆不同颜色的箱子，如果每个颜色都建一个独立材质，那就是 N 种材质，静态合批只能合出 N 批。但如果改用顶点色或者一张调色贴图，让所有箱子共用一个材质，那就能合成一批。这个改动的收益往往比单纯开合批大得多。当然，这涉及美术流程的调整，需要提前跟美术沟通好规范，别等到优化阶段才发现材质乱成一锅粥。

Shader 方面，要确保合批用到的 shader 支持静态合批。绝大多数内置 shader 和标准 PBR shader 都支持，但一些自定义 shader 如果手动处理了顶点变换或者依赖对象空间坐标，合批后可能出现位置错乱。判断方法很简单：合批后如果物体位置不对、法线方向异常、或者光照计算明显偏差，优先怀疑 shader 里用了对象空间数据而没做世界空间转换。

3. 运行时合批：StaticBatchingUtility.Combine 的用法与陷阱

3.1 什么时候需要运行时合批

大部分情况下，静态合批靠构建期烘焙就够了。但有些场景必须在运行时合并：比如程序化生成的关卡、从 AssetBundle 动态加载的场景块、或者需要在运行时把一批物体临时组合起来的特殊需求。这时候就要用到 StaticBatchingUtility.Combine 这个 API。它的作用是把传入的一组 GameObject 的网格合并成静态合批数据，效果等同于构建期烘焙，但发生在运行时。

这个 API 的签名有几个重载，最常用的是传入一个根 GameObject，它会遍历根节点下所有标记为 static 的子物体进行合并；另一个重载是传入一个 GameObject 数组加一个根节点。使用时要注意：合并后的物体不能再移动，否则渲染位置不会更新；合并操作本身有性能开销，不适合每帧调用；合并后的数据会占用内存，动态加载的场景块如果频繁加载卸载，要记得在卸载时释放对应的合批数据，否则内存会持续增长。

3.2 一个可直接复用的运行时合批脚本

下面这个脚本是我在实际项目里用过的一个简化版本，思路是场景块加载完成后，对根节点下的静态物体执行一次合并，并记录合并状态方便后续卸载时清理。

using UnityEngine; public class RuntimeStaticBatcher : MonoBehaviour { [SerializeField] private GameObject sceneRoot; private bool _batched = false; public void BatchScene() { if (_batched || sceneRoot == null) return; // 收集根节点下所有需要合批的渲染器 var renderers = sceneRoot.GetComponentsInChildren<MeshRenderer>(); var gos = new GameObject[renderers.Length]; for (int i = 0; i < renderers.Length; i++) { gos[i] = renderers[i].gameObject; // 确保标记为 static，否则 Combine 会跳过 gos[i].isStatic = true; } // 执行合并，根节点传 sceneRoot StaticBatchingUtility.Combine(gos, sceneRoot); _batched = true; Debug.Log($"运行时静态合批完成，合并物体数：{gos.Length}"); } public void UnbatchScene() { if (!_batched || sceneRoot == null) return; // 卸载时销毁根节点即可释放合批数据 Destroy(sceneRoot); _batched = false; } }

这段代码的关键点在于：合并前必须确保物体的 isStatic 为 true，否则 Combine 会直接跳过；合并的根节点要传对，它决定了合批数据的组织方式；卸载时直接销毁根节点，合批数据会随之释放。实际项目里我还会加一层对象池管理，避免频繁创建销毁根节点带来的 GC 压力。

3.3 运行时合批的三个典型陷阱

第一个陷阱是合并时机。如果在物体还没完成初始化（比如材质还没赋值、网格还没加载完）的时候就调用 Combine，合批数据会基于不完整的网格生成，导致渲染缺失或错乱。正确做法是等所有资源加载完成、物体层级稳定之后再合并。我一般会在场景块的加载回调里做这件事，确保前置条件都满足了。

第二个陷阱是合并后的物体被意外修改。有些逻辑会在运行时改物体的材质属性（比如换颜色、改贴图偏移），如果这个物体已经被静态合批，改材质属性可能不会生效，因为合批后的渲染走的是合并后的材质数据。解决办法是把需要动态改属性的物体排除在合批之外，或者改用 MaterialPropertyBlock 这类不破坏合批的方式改属性。

第三个陷阱是内存泄漏。运行时合批生成的数据挂在根节点上，如果根节点没被正确销毁，合批数据就一直占着内存。动态加载卸载频繁的项目尤其要注意，每次卸载场景块都要确认对应的合批数据被释放了。可以用 Profiler 的 Memory 模块观察，看卸载后内存有没有回落。

4. 合批效果验证与常见问题排查实录

4.1 用 Frame Debugger 看清合批真相

验证静态合批有没有生效，最直接的工具是 Frame Debugger。打开 Window > Analysis > Frame Debugger，抓一帧，然后在左侧的渲染事件列表里找“Static Batch”相关的条目。如果合批生效，你会看到多个物体被归到同一个 Draw Call 下，条目名称通常带有“Static Batch”字样，点开能看到这个批次包含了哪些网格。如果每个物体还是单独的 Draw Call，说明合批没生效，需要往下排查。

排查顺序我一般是这样：先确认 Player Settings 里的 Static Batching 开关开了没；再确认物体是否勾了 Batching Static；然后看材质是不是同一个（材质实例不同合不到一起）；最后看 shader 是否支持。这四步能覆盖八成以上的合批失效问题。Frame Debugger 里还有一个细节值得看：合批后的批次数量是否等于材质种类数。如果批次数量明显多于材质种类，说明有物体因为某些原因没被合进去，比如网格顶点数超限（虽然静态合批理论上没上限，但极端大的网格可能被拆分）或者物体被标记了不该标记的静态子项导致冲突。

4.2 合批后内存暴涨怎么破

静态合批用内存换 CPU，内存涨是预期内的，但涨得离谱就要查原因。最常见的元凶是同一个网格被大量重复摆放。前面算过，一个 5000 顶点的网格摆 100 个，合批后就是 50 万顶点常驻。如果这些物体本来可以用 GPU Instancing 共享网格数据，那静态合批就是亏的。判断标准是：重复摆放次数多、网格顶点数大、且这些物体不需要参与复杂的光照烘焙时，优先考虑 Instancing 而不是静态合批。

另一个内存元凶是合批数据没有随场景卸载而释放。运行时合批尤其容易出这个问题，根节点没销毁，合批数据就一直挂着。用 Memory Profiler 抓快照，看“Mesh”类别的内存占用，如果卸载场景后这部分没降，基本就是合批数据泄漏。解决办法是确保卸载流程里销毁合批根节点，或者用 Resources.UnloadUnusedAssets 强制清理（但这个 API 有性能开销，别频繁调）。

还有一个隐蔽的情况：编辑器里测试时合批数据不会真正释放，因为编辑器保留了场景的编辑状态。所以内存验证一定要用构建包，别在编辑器里看内存曲线就下结论。

4.3 常见问题速查表

这张表里的每一条都是我在实际项目里踩过的，尤其是“编辑器正常构建后异常”这一条，坑过不止一次。编辑器里 Play 模式下的合批行为和构建包不完全一致，有些问题只在构建包里暴露，所以性能验证的最后一公里一定要用真机包跑。

4.4 几个容易被忽略的实操心得

第一个心得：静态合批和遮挡剔除要配合着用。合批减少了 Draw Call，但如果被遮挡的物体还在提交，那合批的收益就被浪费了。给静态物体勾上 Occludee Static 和 Occluder Static，让遮挡剔除系统把被挡住的批次剔除掉，两者叠加效果最好。不过遮挡剔除本身也有烘焙成本，场景大的话要权衡。

第二个心得：合批后的批次顺序会影响渲染效率。Unity 会按材质和渲染队列排序，但如果你有特殊需求（比如某些物体必须优先渲染），可以通过调整材质的 Render Queue 来控制。这个细节在普通项目里影响不大，但在渲染顺序敏感的效果（比如透明物体叠加）里很关键。

第三个心得：别为了合批而合批。有些团队把合批当成 KPI，恨不得所有物体都标静态，结果内存爆了、光照错了、动画也不动了。合批是手段不是目的，目的是降 CPU 开销。如果一个场景的 Draw Call 本来就不高（比如移动端小场景，几十个 Draw Call），那合批的收益可能还不如把精力花在减少材质种类或者优化 shader 上。先测量再优化，别凭感觉。

第四个心得：版本升级后重新验证。Unity 每个大版本对合批的实现细节都可能有调整，比如合批的顶点上限策略、材质分组的排序逻辑、运行时 Combine 的行为。升级引擎后，把之前的合批配置和性能数据重新跑一遍，别假设旧结论还成立。

5. 把静态合批放进整体优化链路里看

静态合批从来不是孤立的一步，它得跟材质合并、图集整理、遮挡剔除、LOD、GPU Instancing 这些手段配合着用，才能把渲染开销压到合理区间。我的习惯是先把场景的渲染数据摸清楚：Draw Call 多少、材质种类多少、重复物体多少、哪些物体在动哪些不动。摸清楚之后，不动的、材质能共用的走静态合批；重复摆放且网格大的走 Instancing；会动的走动态合批或骨骼动画优化；被遮挡的靠遮挡剔除砍掉。每一步都有明确的判断依据，而不是一股脑全开。

还有一个经常被忽略的维度是目标平台。桌面端 CPU 相对宽裕，Draw Call 的容忍度高，静态合批的优先级可以往后放；移动端 CPU 紧张，Draw Call 对帧率影响大，合批的收益更明显，但移动端内存也紧张，合批的内存代价要更谨慎地算。同一个场景在桌面和移动端的最优合批策略可能完全不同，别拿一套配置通吃所有平台。

最后说个我自己的体会：静态合批这个“免费午餐”，免费的是运行时的 CPU 时间，买单的是内存和灵活性。什么时候点这道菜，取决于你的场景里“不动的物体”占多大比例、材质能不能共用、内存预算够不够。把这几个账算清楚，合批才真的划算；算不清楚就盲目开，很容易出现 Draw Call 降了一点、内存涨了一截、还搭进去一堆排查时间的尴尬局面。先测量，再决策，合批只是工具箱里的一件，不是万能钥匙。