开场凌晨两点，渲染组的小李盯着屏幕上惨不忍睹的画面——场景里堆了 200 个动态光源，每个角色身上都挂着粒子特效，主角一转身，帧率直接从 60 掉到 12。CPU 那边也一脸无辜：逻辑代码只跑了 4ms，剩下的时间全被渲染吃掉了。他试过减少光源数量，美术立刻抗议"这还怎么叫次世代？"；试过关掉阴影，性能回来了但视觉也回到了十年前。这就是典型的"光源与几何复杂度耦合"陷阱——传统前向渲染（Forward Rendering）里，每个像素要对每个影响它的光源做一次光照累加，光源数量一上来，片元着色开销直接爆炸。延迟渲染（Deferred Rendering / Deferred Shading）正是为解决这个痛点而生。它用一种"先备料、后统一烹饪"的思路，把几何处理和光照计算拆成两顿来做。这篇文章会讲清楚三件事：它怎么解耦的（机制）、为什么必须付出带宽和透明度的代价（设计权衡）、以及工程上怎么绕开这些坑（实践）。一、延迟渲染核心概念1.1 两阶段渲染管线延迟渲染把渲染流程拆成两个界限分明的 Pass：Geometry Pass（备料）：只绘制不透明几何体，不做任何光照。把每个像素的"原材料"——法线、世界位置（或深度反推）、材质参数（Albedo、金属度、光滑度、自发光）——写入屏幕空间的多张 Render Target，统称G-Buffer；Lighting Pass（统一烹饪）：画一个全屏 Quad（或逐光源画包围体），逐像素从
