做光照调试的人多半都遇到过这样的场面：场景里为了反射效果摆了二三十个反射探针，结果某面金属墙走几步就开始“换滤镜”，反射忽亮忽暗，探针与探针交界处像两块完全不同的环境图硬焊在一起。Unity的反射探针采样混合，是光照里最容易出“玄学问题”的一块。反射探针说白了就是往场景里放若干台“全景相机”，每台相机把自己位置看到的环境烘焙成一张立方体贴图；物体表面的高光反射、镜面反射，全靠运行时去查这些贴图得到。可只要探针一多，影响范围就会重叠，GPU就必须回答一个问题：同一个像素底下，到底该用哪张Cubemap？又该按什么比例混？这篇文章围绕“大量反射探针采样时如何混合效果”这个主题，把选择探针、权重分配、布局调参、性能取舍和常见坑一次性说清楚。适合正在调室内反射、还没搞懂为什么反射总跳变的开发者，也适合准备在项目里大面积铺探针的技术美术。

1. 先搞清楚：反射探针的混合是怎么发生的

1.1 反射探针不是灯光，而是一台六面相机

很多人把反射探针当成“光照”的一种，其实它更像场景里的环境记录仪。探针放在某个位置后，会朝上、下、左、右、前、后六个方向渲染周围环境，生成一张Cubemap。物体表面的反射并不是“实时追光”，而是去查这张环境贴图，再把查到的颜色按粗糙度、金属度做模糊和调制。你可以把它理解为：在房间中心举着一台全景相机拍了一圈照片，房间里的金属球反射的其实是这些照片，而不是真的看到房间。这也是“探针位置”非常重要的原因——站在门口拍的照，和在窗边拍的照，内容完全不一样。

烘焙反射探针记录的是静态环境，适合墙壁、地面、大型建筑这些不太变化的东西。实时反射探针则会在运行时重新渲染六面，能捕捉动态角色、移动物体，但代价也更高。不管哪种类型，只要角色身上穿着高反射材质，最终屏幕上的颜色就一定来自某张Cubemap；探针怎么选、怎么混，直接决定反射是否可信。

1.2 Unity默认混合规则：重要性优先，最多取两张Cubemap

这里先给一个关键结论：Unity内置渲染管线的默认反射采样，并不会把一个像素周围所有探针的Cubemap全部采样一遍再取平均，而是从“最多两个探针”里取数据。系统会把反射探针按重要性排好序，选重要性最高的作为主探针，选次高的作为副探针，两个探针的结果按一个混合权重做插值。权重怎么来？可以理解为由像素位置和两个探针“影响体积”的空间关系决定：像素越深入某个探针的影响范围，那个探针的占比就越高；一旦像素完全离开主探针的影响范围，就会平滑切到副探针。

这个设计是刻意的。如果每个像素都去采样场景里几十张Cubemap，管线和带宽都承受不住。固定取两张，等于把反射采样的成本锁定在一个常数上，探针数量再多也不会让单个像素的采样量线性上涨。代价也很明显：探针布局没规划好时，系统只能在“两张之间二选一”，跳变、硬边、闪图几乎必然出现。

1.3 大量探针时，混合效果真正的瓶颈在哪里

探针一多，混合问题通常集中在三处。第一是选择跳变：像素从探针A的影响范围移动到B时，如果两盒之间没有交叠，或交叠带特别窄，屏幕上就是“啪”一下换图。第二是权重分配不合理：两个探针重要性差太多，低重要度的探针在重叠区域里几乎没有话语权，过渡带被压缩成一条线。第三是捕获内容差异过大：两个探针位置虽然只差几米，但一个能看见窗外强光，另一个正好被柱子挡住，权重再平滑，混合出来的反射也会出现“重影”或闪烁。

所以“大量反射探针如何混合”不是简单的Lerp问题，而是探针布局、参数设置、捕获内容三个层面的综合问题。下面按参数、实操、排查、性能一步步拆。

2. 决定混合效果的几个关键参数

2.1 Importance参数：优先级如何决定“谁被采样”

反射探针组件里的Importance，中文叫重要度，是混合排序的第一依据。数值越大，越优先被当成主探针。听起来简单，实际使用时特别容易踩坑：有人为了让所有探针都“有用”，把几十个探针的Importance全部设成同一个大数，结果系统不知道该优先谁，混合区域反复横跳。

更合理的做法是分级。例如核心展示区的主探针设100，负责大范围过渡的探针设30到50，只在角落补漏的辅助探针设5到10。这样整个区域有一个明确的“反射主导者”，其他探针只在需要时才参与。强调一点：Importance只解决“谁优先”，解决不了“在哪里过渡”的问题。一个探针重要度再高，如果它的影响盒没有覆盖某个物体，它对那个物体就是零贡献。

2.2 影响体积：过渡带发生在哪个空间范围

反射探针的影响体积，就是它在场景里能“管事”的空间范围。配置面板里的Box Size、Box Offset就是干这个的，旧版本也有直接用半径定义范围的。物体只有进入某个探针的影响体积，才会被那个探针影响；两个探针的影响体积重叠的部分，就是混合过渡带。

实际调法记住三条。第一，影响盒要刚好覆盖需要反射的物体，不需要硬塞整个场景。第二，相邻影响盒之间一定要留重叠，重叠宽度大约占盒体尺寸的20%到30%时，过渡看起来比较舒服。第三，不要用一个巨大的影响盒试图“罩住一切”，这样做只会让所有次级探针全部失效，等于手动关掉了混合。可以这样验证：把需要反射的物体放在两个探针影响盒的交叠处，打开Gizmos，移动物体位置，观察混合权重是否连续变化。

注意：如果两个探针的影响盒完全不重叠，它们之间永远不会发生平滑过渡，只会在边界处硬切。

2.3 Box Projection：为什么混合区容易出现“方向撕裂”

Box Projection（盒式投影）是反射探针里很实用但很容易被忽略的选项。开启后，反射采样方向会按照一个盒体修正，让反射内容更符合室内房间的遮挡关系。简单说，它让Cubemap不再是“无限远的全景”，而是被约束在房间尺度里，模拟墙面、地板对反射方向的限制。

大量探针时，这个选项最怕不统一。如果相邻两个探针一个开了、一个没开，它们在混合区不仅颜色不同，连反射方向都不一样。视觉上就是同一块金属表面，左边反射来自墙面方向，右边反射来自窗外方向，中间过渡再平滑也是一道撕裂感。我的建议是：室内场景统一开启Box Projection，室外场景统一关闭；开启时把Box Size对准真实房间尺寸，不要把盒子拉得比房间大很多，否则修正效果会被稀释。

2.4 Culling Mask和分辨率：别让两个探针的画质差太多

Culling Mask控制探针六面渲染时能看到哪些层，相当于给每个探针配了一套“哪些物体该被我拍进去”的名单。Resolution则是Cubemap的分辨率。这两项不直接影响权重，却直接影响混合观感。如果一个高分辨率探针和一个低分辨率探针并肩摆放，过渡带里会出现明显清晰度差异：一面墙反射锐利，另一面墙反射糊成一片，非常出戏。

方案是给探针分档，比如核心探针用256分辨率，辅助探针用128，同一个过渡带两侧的探针尽量保持同一档。Culling Mask也不要省，静态反射场景通常只需要场景层和光照层；粒子、植被、大量小物件、透明特效如果都被探针拍进去，不仅烘焙变慢，反射内容还会更“脏”。

3. 大量探针场景下的实操流程：从布局到烘焙

3.1 先画反射需求图，而不是无脑铺探针

进入实操阶段，第一步不是拉探针，而是先问“哪里真的需要反射”。镜面大厅、金属走廊、水面、玻璃幕墙附近是重点区域；粗糙混凝土墙、大片草地、粒子特效区通常不需要高密度探针。我习惯的做法是：在楼层平面图上把反射需求标注出来，关键区每隔10到15米放一个，次要区每隔20到30米放一个，没有需求就不放。做完规划再统计数量，往往比拍脑袋铺出来的少一半，混合问题也少一截。

这一步的收益在后续调参时会非常明显。探针数量少，影响盒重叠关系清晰，烘焙速度快，运行时调试也不会被几十个Gizmo挡住视线。

3.2 相邻探针重叠度调到多少最不容易跳变

摆放时，随手拖一个探针出来很容易，难的是让相邻探针的重叠关系稳定。推荐流程是：先放主探针，调整Box Size把反射主轴覆盖住；再放次级探针，让它的影响盒边缘压进主探针影响盒内部，重叠宽度大概占盒体尺寸的20%到30%。如果两个探针之间正好是长走廊或连续的金属墙面，可以在中间加一个低重要度的过渡探针，专门负责把A和B的影响串起来。

调整时不要按一次改几十个探针再烘焙一次。效率最高的做法是改两三个探针，用局部烘焙或观察Gizmos验证，确认过渡正常后再继续。这里有个容易忽略的细节：长物体的反射需求经常被低估。一面墙如果超出了单个探针影响盒，墙上半段归A、下半段归B，接缝就出现在墙面上。遇到这种情况，要么扩大影响盒覆盖整面墙，要么在墙中间补探针，别指望权重自动处理好。

3.3 主探针、过渡探针和实时探针怎么分配

一个场景里的探针建议分成三类。主探针负责展示核心区域，重要性最高，影响盒尽量覆盖完整空间；过渡探针负责把主探针之间的空档串起来，重要性中等，影响盒故意和两侧重叠；局部辅助探针负责角落、门洞、材质突变处，重要性较低，只用来修正局部反射。

实时探针是另一套思路。默认情况下，实时探针会按刷新模式渲染六面场景，数量一旦上去了，帧率会肉眼可见地下降。大量探针场景里，主力应该用烘焙探针，动态反射需求单独用少量实时探针解决。比如角色在室内走动，就做一个跟随相机或角色的实时探针，刷新模式用On Awake或Via Scripting，只在需要时更新。运行时同时活跃的实时探针，我一般控制在3个以内，再多就要认真算成本了。

3.4 烘焙、验证与视角测试的完整流程

处理完布局和参数，进入烘焙阶段。在光照窗口里执行反射探针烘焙，等Cubemap生成完，再把一个标准材质球或金属测试球放到关键过渡位置，转动视角观察。验证重点有三个：从区域A走到区域B，反射是否连续变化；站在两个探针混合区转头，是否出现两块反射交替闪烁；金属球边上是否出现清晰硬接缝。任意一项出问题，回到影响盒和Importance里调整。

实时探针的验证还要加一项：刷新模式。如果选了Every Frame，运行时每帧都在重渲六面，帧率压力很大；选了Time Slicing，六面画面会分摊到多帧渲染，峰值压力下降，但移动时反射会有轻微滞后。验证时不仅要看画面是否好看，还要看Profiler里的实际耗时，否则很容易被“编辑器里看起来一切正常”骗过去。

4. 常见混合问题与排查速查

4.1 反射跳变或闪图：最典型的“换探针”问题

反射跳变是大量探针场景里出现频率最高的问题。表现是角色走动时，某个物体表面的反射会突然变一张图，或者在同一位置轻微晃动视角时反射闪烁。排查第一步，打开探针的Gizmos显示，找跳变发生的位置，看那里是不是正好落在某个探针影响盒的边缘。如果是，先扩大影响盒，让相邻探针的重叠带覆盖住这个点。如果已经重叠但还是跳，就看这两个探针的Importance是不是相差过大，导致过渡带被压得太窄。

还有一个隐蔽原因：两个探针捕获内容差异太大。比如探针A能拍到窗外的强光，探针B被柜子挡住拍不到，权重过渡虽然连续，但颜色跳变依旧明显。这种情况单纯调参数没用，需要补一个过渡探针，或者调整探针位置，让两个探针看到的环境内容尽量接近。

4.2 物体明明在探针旁边，却没有任何反射

这个现象容易让人怀疑是Shader问题，其实多数时候是影响盒没覆盖到。反射探针的影响体积是一个明确的空间范围，物体在这个范围外，引擎就认为它不受该探针影响。检查办法：选中物体，看它是否位于至少一个探针的影响盒内；再把材质切到内置Standard，确认不是自定义Shader根本不采样反射探针。

如果物体在影响盒内但仍无反射，检查Culling Mask。探针渲染六面时会把不属于指定层的物体排除在外，如果物体所在层被探索针的Culling Mask剔掉了，它自然不会被“拍”进Cubemap。最后，实时探针如果还没触发刷新，或者烘焙数据没保存，也会出现黑反射。按这个顺序排查，绝大多数“无反射”都能定位。

4.3 Box Projection与盒体尺寸引起的反射偏移

开启Box Projection后，反射内容的正确性高度依赖Box Size和Box Offset。Box比实际房间小，反射墙面的位置就会往里缩，物体上的倒影看起来飘了半米；Box偏移没对准房间中心，整个反射方向会歪向一侧。这类问题视觉效果很“玄”，但排查起来相对简单：对照房间的真实尺寸，重新设置探针的Box Size，并把Box Offset对准探针相对房间中心的位置。

另一类接缝来自开关不统一。同一个混合区域里，如果一侧探针开着Box Projection，另一侧没开，接缝处会出现“方向撕裂”——反射内容在颜色上还算连续，但几何方向明显从房间内跳到无限远处。统一开关状态，比调任何权重参数都有效。

4.4 帧率下降、烘焙变慢、包体变大的连锁反应

探针数量增加后，最常见的是运行时帧率下降。先打开Profiler，看GPU端是否有大量“Reflection Probe”相关耗时；如果是，优先检查实时探针的Refresh Mode，把Every Frame改成On Awake或Via Scripting。次常见的是烘焙变慢，这往往和探针数量、Cubemap分辨率、Culling Mask里的物体复杂度成正比。一个场景几十个探针如果全用512以上分辨率，烘焙时间翻倍都不止。

包体变大则主要来自Cubemap资源本身。一个256分辨率的立方体贴图，六面加mipmap大约2MB；几十个探针就是几十MB。如果不做压缩、不砍分辨率，移动端项目很容易在这里吃大亏。定期检查烘焙出来的探针资源大小，把不重要的探针降到128，效果通常不会差太多。

4.5 一个按优先级排的排查顺序表

这张表里的顺序很重要。先确认“空间覆盖”，再调整“权重参数”，最后才考虑Shader和性能，能少走很多弯路。

5. 性能与资源：大量反射探针的正确打开方式

5.1 按“反射需求”决定探针数量，而不是按面积

很多人会把探针当成“覆盖问题”：只要面积够大，探针就得铺满。其实更合理的判断标准是“反射内容变化是否显著”。在拐角、门洞、材质由粗糙变光滑的地方，反射内容变化大，需要额外探针；在空旷又粗糙的地面上，反射内容几乎不变，少放甚至不放都可以。按这个逻辑做，探针数量会明显下降，混合网络也不会那么乱。

我之前调过的一个室内测试场景，最初按“每个房间放两个”的思路摆了四十多个探针，反射区域重叠得一团糟。后来改成“反射重点区加强、非重点区删减”，探针数量砍到二十出头，画面几乎没有损失，烘焙时间却省了一半。反射混合并不是探针越多越细腻，探针太多只会让选择逻辑混乱。

5.2 实时探针：控数量、控更新、控渲染层

实时反射探针是性能的大头。它每次更新都要把场景重新渲染六遍，等于临时多出六台相机在一个位置拍周围。哪怕场景很简单，这个开销也不小。控制手段有三个：数量、更新频率、渲染内容。

数量上，运行时同时活跃的实时探针控制在3个以内；更新频率上，优先用On Awake或Via Scripting，不要Every Frame；渲染内容上，把Culling Mask里的粒子、植被、透明特效全部去掉，只保留会影响反射的核心场景层。如果角色需要在移动中反射周围动态环境，做“跟随角色的单个探针”，用脚本在角色移动一定距离后触发更新，比给每个动态物体单独放探针划算得多。

5.3 用公式估算探针内存和烘焙成本

Cubemap内存可以粗算：宽×高×6面×每像素字节×mipmap系数。以RGBA32为例，256×256×6×4字节×约1.33，约2MB；128分辨率则约0.5MB。如果场景里有30个探针，128档位大约15MB，256档位大约60MB。项目如果还要兼顾移动端，这个数字是必须提前算的。

烘焙成本则与分辨率成平方关系：分辨率从128升到256，需要渲染的像素数是原来的4倍；探针数量从20个涨到40个，烘焙时间基本线性翻倍。所以更稳妥的做法是先用128烘焙一版，跑通视觉效果，再只对核心探针升到256。不要让全场景都跟着升档，性价比太低。

5.4 不同渲染管线对大量探针混合的支持差异

内置渲染管线对“一物体最多两个探针、按重要性排序混合”这套规则支持得最稳定。URP的情况就复杂一些，部分版本对反射探针的兼容和混合能力有限，可能不会自动做多个反射探针的平滑混合，或者只采样一个主要探针。上手前先确认你用的管线版本对反射探针的定义，不要拿内置管线的经验直接套。

HDRP的反射体系又不一样，反射探针、屏幕空间反射、体积雾和天空环境是配合使用的，探针参数里多出来的选项也和内置不同。大量探针布局的经验仍然成立，比如影响盒重叠、优先烘焙、控制实时探针数量，但具体参数名和混合算法需要按管线文档重新对齐。

6. 如果想要更多控制权：自定义Shader和脚本

6.1 默认Shader背后的“两张Cubemap做Lerp”

内置Shader处理反射探针时，引擎会把当前最重要的两个探针填充到全局着色器变量里：一个主探针、一个副探针，以及Box Projection所需要的盒体边界信息。像素着色器拿到反射方向后，分别去两张Cubemap里采样，再按权重做一次Lerp。下面这段是示意，不是内置Shader原文，但能表达混合思路：

// 伪代码，只表达混合思路，不是内置Shader原文 float3 dir0 = BoxProjectedDir(reflectDir, unity_SpecCube0_ProbePosition, unity_SpecCube0_BoxMin, unity_SpecCube0_BoxMax); float3 dir1 = BoxProjectedDir(reflectDir, unity_SpecCube1_ProbePosition, unity_SpecCube1_BoxMin, unity_SpecCube1_BoxMax); float3 env0 = texCUBE(unity_SpecCube0, dir0).rgb; float3 env1 = texCUBE(unity_SpecCube1, dir1).rgb; float3 finalColor = lerp(env0, env1, blendWeight);

从这段可以看出，探针数量再多，Shader侧也不会看到几十张Cubemap。理解这一点，你就明白为什么探针参数没设好时会出现“二选一”效果。想彻底改变混合策略，只能在自定义Shader里绕开这套默认机制。

6.2 运行时脚本能干预哪些混合行为

脚本可以干预的常见行为有三类。第一，动态调整两个探针的Importance，让过渡区跟着角色移动，而不是固定死在某个空间位置。第二，控制实时探针的更新时机，比如角色进入某个区域才触发刷新，离开后切回烘焙数据。第三，对特殊材质关闭默认反射探针采样，改在Shader里用自定义环境贴图，获得完全独立的反射控制。

要注意的是，默认混合权重不完全暴露在材质属性里，不能简单通过MaterialPropertyBlock去覆盖引擎自动算好的权重。脚本能做的是改变探针的空间参数和优先级，从而影响引擎的排序和范围判断。自定义Shader才是控制最终反射采样方式的可靠入口。

6.3 让布局规范代替事后调参

大量反射探针的混合问题，真正稳定可靠的解法是提前定规范，而不是每次都靠临时调参救火。项目初期就应该约定：探针分几级、每级Importance范围是多少、影响盒重叠保持多少、Cubemap分辨率统一在哪两档、实时探针上限是多少。技术美术和渲染程序对这个规范达成一致后，后续场景新增探针时会自动按照同一套逻辑排布，混合问题会大幅减少。

我个人在实际操作中的体会是：反射混合调试很像整理一团乱线，与其在线团里扯来扯去，不如先停下来规定每一根线的路径。大量反射探针的采样混合，核心思路永远是“排序清晰、过渡有重叠、内容差异小”。做到这三点，默认系统已经能给你相当平滑的反射效果；做不到，再高级的Shader和脚本也只是在补救布局问题的后果。