我不确定您的问题是否是关于何时可以在 glBegin/End 内调用 glGetError 或者这是否是关于 glGetError 一般用法的更普遍的问题。所以我会回答两个。
在 glBegin 和 glEnd 之间可以做的事情非常有限。这是故意的，因为您将 GL 置于非常特定的模式 - 在平局中间。因此，任何与每个顶点属性不直接相关的内容都是无效的。即使是 glGetError 在这种情况下也是无效的。尝试将 glBegin+之间的所有 GL 调用+glEnd 视为对 GL 的单个 Draw 调用，这有助于更接近 GL 真正所做的事情。
现在，如果您坚持仅调用属性方法（glNormal、glTexCoord、glColor、glSecondaryColor、glIndex、glMultiTexCoord、glVertexAttrib、glVertex 和其他一些方法）的简单规则，那么在 Begin/End 对内，您永远不会真正触发 GL 错误）。其他任何事情都会触发错误。 （呃...好吧，glMaterial 是一个例外。它可以工作，但不鼓励使用它）
如果您的问题是当错误在 Begin/End 对内触发时何时可以调用 glGetError，ChrisF 在评论中回答：在 glEnd 调用之后。
现在，从更广泛的意义上来说，仅使用 glGetError 作为调试工具。我个人的偏见有两个：
- 每帧检查一次 glGetError 以确保没有错误
- 使用可以检查 GL 错误代码的宏包装大多数 GL 调用，并且仅在每帧检查失败时才将其打开。
当然，既然可以调用属性方法outside一对开始/结束，要让它们正确有点棘手。但实际上，这些方法无论如何都不会失败，所以我懒得去宏观检查它们。
趣闻：GL API 最初设计的目的是让客户端实现实际上不知道调用站点是否存在错误。例如。如果 GL 实际上是在远程计算机中实现的（就像在 SGI 时代一样），那么对目标不是 GL_TEXTURE_ENV 的 glTexEnv 的调用可以简单地添加到命令缓冲区中，并且此时不会记录任何错误。
如果您随后调用 glGetError，则客户端必须将命令缓冲区刷新到 GL 服务器，等待处理缓冲的命令，获取错误代码，并将适当的错误代码返回给应用程序。
如果这听起来很沉重，那是因为事实确实如此。顺便说一下，这就是为什么不是每个调用都返回错误代码的主要原因，也是为什么调用 glGetError 仅被认为可以用于调试目的。如今，大多数 GL 实现都在同一进程中处理所有状态管理，因此正如我所说，这对于大多数用户来说确实是一件小事。
最后，每当我谈论开始/结束时，我觉得我需要说你可能应该考虑根本不使用它。这是使用 GL 进行绘制的性能最差的方式。
