开场凌晨两点，小李盯着 Frame Debugger 里那条黄色的 "SRP Batcher: not compatible" 警告，血压飙升。同一个 Shader，同事电脑上跑得好好的，自己这边就死活不生效。他已经把材质球精简到只挂一个 Texture，Project Settings 也逐条核对过——就是不行。后来他发现，问题出在 Shader 里一句看起来人畜无害的float4 _Color;。这句声明没写进CBUFFER_START(UnityPerMaterial)里，直接裸露在 HLSL 顶层。SRP Batcher 的兼容性检查直接判定：这个 Shader 的逐材质数据没有“统一入口”，不可批处理。改完一行代码，Frame Debugger 立刻变绿。这就是 SRP Batcher 最反直觉的地方：它不是“开了就自动变快”的开关，而是一套严格到近乎偏执的布局契约。上一篇讲了它“减负 CPU”的整体逻辑，这篇我们沉到 Shader 代码层，看清“缓存”到底缓存的是什么、契约到底约束了什么。先交代一个前提，免得你后续有困惑：本文谈的“缓存”不是 LRU 之类的淘汰缓存——SRP Batcher 不会“缓存满了把旧材质踢出去”。它更接近“持久化的共享内存”：材质属性一旦写入区段，就一直住在那块显存里，直到材质销毁或属性变化才动。所以工程问题的重点从来不是“缓存怎么换出”，而是“怎样让区段尽量不被重写、让布局尽量能命中”——理解这个前提，后面几章读起来会顺很多。一、SRP Batcher 的 CBUFFER 缓存契约1.1