OpenGL着色器编译错误检查时机及异常问题排查

1. 编译错误检查的时机 #

编译错误是针对单个着色器对象的操作，和是否将着色器附加到程序对象、是否执行glLinkProgram完全无关。正确的流程是：

• 创建着色器对象 → 写入着色器源码 → 调用glCompileShader(shader) → 立即调用检查函数获取GL_COMPILE_STATUS和编译日志
  整个过程不需要涉及程序对象（glCreateProgram、glAttachShader、glLinkProgram这些步骤都不用），因为编译是着色器对象自身独立的操作。

2. 为什么会出现“GL_INFO_LOG_LENGTH为0但GL_COMPILE_STATUS为0”的异常 #

你遇到的问题根源是根本没正确执行编译操作：你调用的是glCompileShader(int(type))，而非真正的着色器对象ID（shader变量）。这相当于给glCompileShader传了一个无效的ID（type是着色器类型枚举，比如GL_VERTEX_SHADER，数值很小，不是有效的着色器对象ID），OpenGL不会执行任何编译操作，此时着色器对象的编译状态是未定义的。

这种情况下调用glGetShaderiv获取GL_COMPILE_STATUS返回0是无意义的——没有编译过程，自然不会生成编译日志，GL_INFO_LOG_LENGTH为0是正常状态，但读取日志时因为没有有效数据，就会出现乱码（读取的是内存里的随机值）。你调整日志逻辑、内存分配方式这些操作都没触碰到根源问题，自然解决不了。

3. 为什么没正确编译着色器，程序还能链接运行 #

这属于OpenGL驱动实现的不一致性：
严格来说，当程序对象附加了未编译成功的着色器时，glLinkProgram应该返回GL_FALSE，链接失败，程序对象不可用。但部分驱动会做“宽容”处理：比如如果着色器代码为空，或者驱动默认了一个空的着色器实现，或者你的程序在运行时没有触发实际的绘制调用（驱动优化跳过了无效程序的使用），就会出现看似“运行正常”的情况。

但这不是标准行为，换个驱动或者GPU可能就会直接崩溃或者报错，绝对不能依赖这种情况。

内容的提问来源于stack exchange，提问作者Chris