引子：小明的"谁来喊停"之问上一篇，小明彻底搞懂了 Early-Z 这项"未卜先知"的黑魔法——GPU 偷偷把深度测试提前到着色之前，省下被遮挡像素的昂贵着色。他也记住了那条军规：一旦着色器里"改了深度"或"用了 discard"，Early-Z 就会失效，退回缓慢的标准顺序。可当他合上书，一个新的、极其尖锐的问题，又猛地攫住了他："等等……‘着色器里用了 discard，Early-Z 就失效’——这话说得轻巧。可问题是:GPU 或者引擎,它到底是’怎么知道’我这个着色器里,偷偷用了 discard、偷偷改了深度的?!着色器是我写的一段程序啊。GPU 又不会’读心术’,它凭什么在真正运行之前,就断定’哦,这家伙会改深度,我得关掉 Early-Z’?难道它把我的着色器代码,从头到尾读了一遍、看懂了?这个’检测’的过程,到底是谁、在什么时候、用什么手段完成的?!"小明这一问，问到了整个图形渲染管线里一个极其底层、却又鲜有人深究的角落——Early-Z 失效的"检测机制"。是的，GPU 不会读心术。但它背后，站着一位"火眼金睛"的角色——着色器编译器（Shader Compiler）。正是这位"编译器医生"，在你的着色器真正上场之前，就已经像老中医"望闻问切"一样，把你的代码从里到外**“诊断”**了个遍，精准地揪出了那些会"破坏