如果你正在学现代OpenGL，VBO、VAO、EBO这三个缩写大概率会同时出现在你面前。它们是核心模式（Core Profile）下最基础的三个缓冲对象，也是从“会调API”到“真正理解GPU怎么干活”之间必须跨过的一道坎。这篇笔记会把三者的职责、配合方式、典型流程拆开揉碎讲清楚，附上可以复现的代码骨架和实践中常见的坑。无论你是刚学图形学的学生、准备图形学面试的求职者，还是在地图、可视化、工控项目里需要自己画点东西但被OpenGL折腾过的工程师，这篇都值得存下来当参考。
注意：本文以OpenGL 3.3及以上核心模式为准，所有代码思想不受语言限制，示例用C++风格写出。
1. 为什么是VBO、VAO、EBO：一次绘制背后的数据旅程
很多人第一次接触这三个名词是懵的：不都是“缓冲对象”吗，为什么要分三种？这要从现代OpenGL最根本的变化说起。
1.1 核心模式把CPU和GPU之间的“数据界面”彻底改了
早年的OpenGL用glBegin/glEnd立即模式画图，代码大概长这个样子：
glBegin(GL_TRIANGLES); glVertex3f(0.0f, 0.5f, 0.0f); glVertex3f(-0.5f, -0.5f, 0.0f); glVertex3f(0.5f, -0.5f, 0.0f); glEnd();每一次glVertex3f调用，CPU都会把顶点数据从内存拷贝到显存，传给GPU处理。这种方式有三宗罪：数据每帧都在重复传输、渲染状态散落在几百个状态位里难以管理、GPU的并行优势根本发挥不出来。所以在3.2版本之后，OpenGL直接把这个API从核心模式里移除了——官方态度非常明确：改用缓冲对象（Buffer Object），先把数据一次性塞进GPU，再让GPU用最快的速度反复读取。
这个改动背后其实是硬件架构的变化。现在GPU是一套拥有独立显存、独立指令流的高度并行处理器，CPU和GPU之间有总线带宽的限制。想画得流畅，就必须把“数据传输”和“数据解析规则”都固化下来，减少每一次draw call的CPU开销。于是就有了三种缓冲对象的分工。
1.2 一个draw call的完整数据链条
拿一个最简单的三角形来说，一次glDrawArrays(GL_TRIANGLES, 0, 3)背后发生了这些事：
- CPU端准备好一个顶点数组，比如
float vertices[] = {x,y,z, r,g,b, ...}。 - VBO把这份数组上传到显存里存起来。
- VAO记录下“这份数据在哪、每个属性怎么从字节流里切出来”的规则。
- 顶点着色器按VAO里记录的规则，从VBO中取出位置、颜色等属性，逐顶点执行。
- 图元装配、光栅化、片元着色器逐一上场，最终把颜色写到帧缓冲里。
如果数据里有大量重复顶点，EBO还能帮我们省下一大块显存和传带带宽——这个后面细说。
换句话说，一句话总结三者的关系：VBO存“数据”，EBO存“索引”，VAO存“怎么解释这些数据”。三者配合，才能把一个静态的顶点数组变成GPU能高效处理的渲染管线输入。
1.3 顺便回应一个热搜问题：OpenGL能做球形渲染吗
搜索热词里有一条“opengl能做球形渲染吗”，答案当然是可以。球体在OpenGL里没有“球”这个原生概念，它本质上是大量三角面片拼接起来的网格：生成球面上的顶点坐标、法线、纹理坐标，再把顶点按三角形索引组织成EBO，最后交给VBO+VAO渲染。换句话说，不管你要渲染的是三角形、立方体、球体还是整个游戏场景，最后落到API层面全是VBO、VAO、EBO的排列组合。能把这三套东西吃透，后面所有渲染功能都有根基了。
2. VBO：最底层的“顶点仓库”，把数据真正放进显存
VBO全称Vertex Buffer Object，是三种缓冲对象里最直觉的一个。它的本质就是一块GPU显存，用来存放顶点属性数组——位置、颜色、法线、纹理坐标、骨骼权重，都可以往里堆。
2.1 VBO的生命周期：创建、绑定、填充、配置、绘制
一个VBO从生到死要经历这几个步骤：
GLuint vbo; glGenBuffers(1, &vbo); // 1. 生成一个缓冲对象ID glBindBuffer(GL_ARRAY_BUFFER, vbo); // 2. 绑定到目标(GL_ARRAY_BUFFER) glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW); // 3. 分配显存并上传数据 // 4. 配置顶点属性指针（这一步和VAO一起做，下一节细说） // 5. 绘制 glDeleteBuffers(1, &vbo); // 6. 释放很多人搞不懂第2步这个glBindBuffer到底在干嘛。OpenGL本质是一个状态机，GL_ARRAY_BUFFER是一个全局绑定点。你调用glBindBuffer(GL_ARRAY_BUFFER, vbo)，意思是“从现在开始，所有针对GL_ARRAY_BUFFER的操作都作用于vbo这个对象”。后面调glBufferData时，函数内部就知道该把数据写到哪个对象上。同类型同时只能绑定一个缓冲，所以当你需要操作多个VBO时，就得反复绑定。这种设计对GPU驱动友好，但对程序员不友好——于是才有了VAO来帮我们把绑定的状态打包管理。
2.2 glBufferData的参数细节：size、data、usage
glBufferData的签名是：
void glBufferData(GLenum target, GLsizeiptr size, const void* data, GLenum usage);target：GL_ARRAY_BUFFER，表示这是一个顶点属性缓冲。size：要分配的显存字节数，不是元素个数。比如vertices有9个float（3个坐标），那size就是9 * sizeof(float)。data：可以传CPU端数组指针，驱动会把这段内存拷贝到显存；也可以传nullptr，表示只分配不初始化，之后再用glBufferSubData或glMapBuffer填充。usage：不是“显存/内存”的硬性开关，而是给驱动的一个性能提示，告诉它这个缓冲的数据会被怎么使用。
usage有三个维度：
| usage | 含义 | 典型场景 |
|---|---|---|
| GL_STATIC_DRAW | 数据只设置一次，被绘制多次 | 静态模型、地形 |
| GL_DYNAMIC_DRAW | 数据会多次修改，但每次绘制内容变化不大 | 粒子系统、骨骼动画的骨骼矩阵 |
| GL_STREAM_DRAW | 数据每次绘制都会变化 | 每帧更新的调试线条、动态UI顶点 |
我自己的经验是：如果搞不清该选哪个，先无脑用GL_STATIC_DRAW，跑通了以后再去优化。绝大多数学习项目和数据变化不频繁的工业可视化项目，GL_STATIC_DRAW完全够用。频繁重新glBufferData反而会造成驱动内部的性能抖动，因为每次都要重新分配显存。如果数据每帧都要改，正确做法是开始时用glBufferData分配好最大容量，然后用glBufferSubData更新某一段区域。
2.3 顶点属性指针：告诉GPU怎么切数据
数据上传到GPU之后，GPU并不知道这段字节流里哪个4字节是x坐标，哪个4字节是颜色。这里就需要glVertexAttribPointer登场了，它是VBO和着色器之间的“翻译官”。
glVertexAttribPointer( 0, // 顶点属性位置（对应着色器里 layout(location=0)） 3, // 该属性由几个分量组成，这里是 x,y,z共3个 GL_FLOAT, // 分量类型 GL_FALSE, // 是否归一化到[0,1]或[-1,1] 3 * sizeof(float), // 步长（stride）：两个顶点之间的字节偏移 (void*)0 // 该属性在一段顶点数据里的起始字节偏移 );这里有个经典易错点：最后一个参数虽然类型是void*，但它不是CPU指针，而是“字节偏移量”。当只有一个属性数组时，偏移量是0；当顶点数据包含位置+颜色+法线多个属性时，每个属性的偏移量要按字节仔细算。比如一个顶点占8个float（pos3 + color3 + uv2），步长就是8 * sizeof(float)，颜色起始偏移是3 * sizeof(float)，uv起始偏移是6 * sizeof(float)。
另外，GL_FALSE表示不把整数归一化。如果你的顶点属性是GL_UNSIGNED_BYTE类型的颜色值（0~255），并且想在着色器里拿到0.0~1.0的浮点数，这里就要填GL_TRUE，驱动会把数据除以255。这个参数面试经常问，实际项目里颜色压缩存储时也真的会用到。
配好指针之后，还有一个关键的glEnableVertexAttribArray调用。它的作用是把该属性通道打开，否则就算你配置了指针，GPU也不会去读那部分数据。这个函数往往和glVertexAttribPointer成对出现，忘掉它的直接后果就是画面里啥都画不出来，或者画出来一团乱几何。
3. EBO：用索引绘制避免顶点“大锅炖”
VBO能解决数据存储问题，但遇到有重复顶点的几何体时，它的浪费就暴露出来了。
3.1 问题：一个矩形四个顶点，为什么要写六个顶点？
用GL_TRIANGLES画一个矩形，需要两个三角形。如果不用索引，你得交6个顶点（每个三角形3个），但矩形的4个角其中2个是被两个三角形共享的，意味着那2个顶点要在顶点数组里重复写两遍。数据量小的时候无所谓，如果是一个500万三角形的角色模型，重复顶点带来的显存浪费和带宽消耗就非常可观了。
更糟糕的是，如果这个模型要逐顶点做骨骼蒙皮、法线编辑，重复顶点意味着你的顶点处理流程也要重复执行多次，白白浪费GPU算力。EBO（Element Buffer Object，也叫Index Buffer）就是为了解决这个问题而存在的。
3.2 EBO的用法：数据存一份，索引画两次
EBO的用法和VBO高度相似，只是绑定目标不同、数据类型不同：
// 矩形四个顶点 float vertices[] = { // 位置 // 颜色 -0.5f, -0.5f, 0.0f, 1.0f, 0.0f, 0.0f, // 左下 0.5f, -0.5f, 0.0f, 0.0f, 1.0f, 0.0f, // 右下 0.5f, 0.5f, 0.0f, 0.0f, 0.0f, 1.0f, // 右上 -0.5f, 0.5f, 0.0f, 1.0f, 1.0f, 0.0f, // 左上 }; // 索引数组：两个三角形，共6个索引 unsigned int indices[] = { 0, 1, 2, // 第一个三角形：左下、右下、右上 0, 2, 3 // 第二个三角形：左下、右上、左上 }; GLuint ebo; glGenBuffers(1, &ebo); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo); glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);绘制时从glDrawArrays(GL_TRIANGLES, 0, 3)换成：
glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);glDrawElements的第二个参数是要绘制的索引个数，第三个是索引类型，第四个是索引数组在EBO里的字节偏移量。绘制时GPU会按indices里存的顺序去VBO里取顶点，然后按三角形组装。
这里有一个值得注意的细节：glDrawElements的索引类型建议用GL_UNSIGNED_INT（4字节），因为它能覆盖很大范围的顶点数；但如果你的顶点数少于65536个，用GL_UNSIGNED_SHORT（2字节）可以让索引缓冲体积减半，在某些低带宽平台上会有可感知的性能提升。代价是当模型顶点数超过65535时，索引值会溢出混乱，画面会出现明显的“乱拉线”几何错误。
3.3 glDrawArrays与glDrawElements的取舍
这两个函数没有绝对的好坏，纯粹看场景：
| 场景 | 推荐 |
|---|---|
| 几何体顶点不重复，或三角形彼此独立 | glDrawArrays |
| 网格有大量共享顶点（模型、地形、球体） | glDrawElements |
| 顶点数量少，索引管理反而复杂 | glDrawArrays |
还有一个隐藏的坑：如果索引数组里某个索引值超过了顶点数组的边界，驱动程序的行为是不确定的——轻则画面撕裂，重则直接崩溃（有的驱动会返回GL_INVALID_OPERATION）。所以动态生成索引时一定要做越界校验，尤其是程序化生成网格、LOD切换的时候。
4. VAO：把“怎么读数据”打包成状态
VBO负责把数据放进显存，EBO解决了顶点去重，但还有一个问题没解决：顶点属性指针的配置和绑定状态是一堆散落在OpenGL状态机里的全局状态，每次切换物体都要重新配一遍，不仅繁琐，而且极易出错。VAO（Vertex Array Object）就是来解决这个的。
4.1 为什么现代OpenGL把VAO当成了强制要求
在OpenGL 3.3核心模式下，没有绑定任何VAO就调用glVertexAttribPointer，会直接产生GL_INVALID_OPERATION错误。到了4.x时代，这个要求更加严格。理由其实很简单：OpenGL是一个状态机，而顶点属性配置是状态机里最容易出错的那块。VAO把一组相关的状态打包成一个对象，绑定一个VAO就等于恢复了一整套顶点解析规则，画完再绑定另一个VAO，上下文切换非常干净。
打个比方：VBO是仓库里的货架，EBO是取货清单，VAO则是一个“已装配好所有取货规则的工作台”。你把货架推到工作台旁边，告诉工作台“先取位置，再取颜色，间隔8个float”，然后把这套规则保存起来。之后每次要用这批货，只要把工作台推出来就行，不用重新说明规则。
4.2 VAO的创建与绑定流程
GLuint vao; glGenVertexArrays(1, &vao); // 先绑定VAO glBindVertexArray(vao); // 下面这几条调用都会“记录”到当前绑定的VAO里 glBindBuffer(GL_ARRAY_BUFFER, vbo); glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)0); glEnableVertexAttribArray(0); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo); // 配置完成，解绑VAO（避免后续修改影响它） glBindVertexArray(0);这里有一个很多人容易忽略的细节：当VAO绑定且GL_ELEMENT_ARRAY_BUFFER上绑定了某个EBO时，这个EBO的绑定关系会被“记入”VAO。之后只需要glBindVertexArray(vao)，EBO也会自动恢复绑定，不需要再手动glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ...)。
但注意，GL_ARRAY_BUFFER的绑定不会被VAO完整记录。glVertexAttribPointer调用时，驱动程序会把“当前绑定到GL_ARRAY_BUFFER的那个VBO”保存为这个属性数据来源的引用。这意味着，你必须在调用glVertexAttribPointer之前把正确的VBO绑定到GL_ARRAY_BUFFER上。配置完成后，即使你解绑了VBO，VAO里保存的顶点属性仍然会正确引用那个VBO。所以绘制时只需要绑定VAO，不必再绑定VBO。
4.3 一个常见的误解：VAO到底存了什么
VAO不是数据缓冲，它不保存VBO的内容，只保存五类信息：
glEnableVertexAttribArray/glDisableVertexAttribArray的开启状态。- 通过
glVertexAttribPointer配置的属性格式：分量个数、类型、是否归一化、stride、offset。 - 与每个属性关联的VBO引用。
- 绑定的
GL_ELEMENT_ARRAY_BUFFER（EBO）引用。 - 下面还会提到的
glVertexAttribDivisor等实例化绘制相关设置。
数据本身的增删改完全不影响VAO的有效性。比如你画完一帧后，用glBufferSubData把VBO里的顶点位置全部改掉，VAO不需要重新配置，下一次绘制直接用就行。这也为骨骼动画、布料模拟这类每帧更新顶点数据的场景提供了很大的便利。
另外，多个VAO可以共享同一个VBO，只要各自的属性解析规则不同，就能从同一份数据里读出完全不同的渲染效果。比如一份顶点数据既用于正常网格渲染，又用于法线可视化，两个VAO用不同的属性偏移和布局即可实现，不需要复制数据。
5. 完整演练：用一套VBO+EBO+VAO画一个彩色矩形
讲了这么多理论，接下来把三者串起来走一遍完整流程。这个例子是能直接编译运行的最小可复现版本，建议亲手敲一遍，比读十遍笔记都有用。
5.1 顶点数据和着色器准备
// 四个顶点，每个包含 position(3) + color(3) float vertices[] = { -0.5f, -0.5f, 0.0f, 1.0f, 0.0f, 0.0f, // 0: 左下 0.5f, -0.5f, 0.0f, 0.0f, 1.0f, 0.0f, // 1: 右下 0.5f, 0.5f, 0.0f, 0.0f, 0.0f, 1.0f, // 2: 右上 -0.5f, 0.5f, 0.0f, 1.0f, 1.0f, 0.0f, // 3: 左上 }; unsigned int indices[] = { 0, 1, 2, // 第一个三角形 0, 2, 3 // 第二个三角形 };顶点着色器：
#version 330 core layout(location = 0) in vec3 aPos; layout(location = 1) in vec3 aColor; out vec3 vColor; void main() { gl_Position = vec4(aPos, 1.0); vColor = aColor; }片元着色器：
#version 330 core in vec3 vColor; out vec4 FragColor; void main() { FragColor = vec4(vColor, 1.0); }如果你想把顶点属性拆成两个location，那么在配置VAO时就需要多配一组属性指针：
// location=0: 位置 glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)0); glEnableVertexAttribArray(0); // location=1: 颜色 glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)(3 * sizeof(float))); glEnableVertexAttribArray(1);5.2 初始化阶段的完整代码
// 1. 创建并绑定VAO GLuint vao; glGenVertexArrays(1, &vao); glBindVertexArray(vao); // 2. 创建并填充VBO GLuint vbo; glGenBuffers(1, &vbo); glBindBuffer(GL_ARRAY_BUFFER, vbo); glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW); // 3. 配置顶点属性 glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)0); glEnableVertexAttribArray(0); glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), (void*)(3 * sizeof(float))); glEnableVertexAttribArray(1); // 4. 创建并填充EBO GLuint ebo; glGenBuffers(1, &ebo); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo); glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW); // 5. 解绑（可选，但习惯好） glBindVertexArray(0); glBindBuffer(GL_ARRAY_BUFFER, 0); glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);5.3 主循环的绘制调用
// 每帧渲染时： glClear(GL_COLOR_BUFFER_BIT); // 绑定VAO，前缀全部恢复 glUseProgram(shaderProgram); glBindVertexArray(vao); glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0); glBindVertexArray(0);这里你可能会想：“这个矩形坐标不是屏幕坐标，为什么能直接显示？”因为顶点着色器里我们直接把aPos赋给了gl_Position，没有经过任何变换。OpenGL的NDC坐标范围是[-1,1]，矩形的四个顶点正好在这个范围内，所以它占满了窗口中央。
5.4 动态更新顶点数据的方法
如果顶点数据每帧都在变，比如粒子系统、波形显示，GL_STATIC_DRAW就不合适了。你需要在初始化时就把缓冲容量分配好，然后在每帧更新数据：
// 初始化时： glBufferData(GL_ARRAY_BUFFER, maxVertexCount * sizeof(Vertex), nullptr, GL_DYNAMIC_DRAW); // 每帧更新时： // 方法一：glBufferSubData 更新一段区域 glBindBuffer(GL_ARRAY_BUFFER, vbo); glBufferSubData(GL_ARRAY_BUFFER, 0, currentVertexCount * sizeof(Vertex), vertices); glBindBuffer(GL_ARRAY_BUFFER, 0); // 方法二：glMapBuffer 直接映射显存指针（更高效） glBindBuffer(GL_ARRAY_BUFFER, vbo); Vertex* ptr = (Vertex*)glMapBuffer(GL_ARRAY_BUFFER, GL_WRITE_ONLY); memcpy(ptr, vertices, currentVertexCount * sizeof(Vertex)); glUnmapBuffer(GL_ARRAY_BUFFER); glBindBuffer(GL_ARRAY_BUFFER, 0);注意glMapBuffer返回的指针不是普通CPU指针，不要跨帧保存它，一定要在glUnmapBuffer之前完成读写。这是我见过很多人踩的坑：映射后忘了解绑，下一帧再映射时驱动要么返回同一个指针导致数据互相覆盖，要么直接报错。
6. 我在实际项目中踩过的坑与调试技巧
三件套单独看不难，但组合起来出错时，画面上往往只有一个黑屏或者一团乱麻，排查起来很折磨人。这里把我反复踩过、也帮别人查过的几个典型问题列出来，每个都附上排查思路。
6.1 想当然地把glVertexAttribPointer最后一个参数写成指针
这个错误出现的频率高到离谱。很多教程示例代码里写的是(void*)0，于是有人照葫芦画瓢，但在嵌套多层结构体、自己写Wrapper类时，容易把最后一个参数误写成&vertices[0]，或者写成了vertices。结果就是GPU从错误的地址读数据，图形要么完全不出来，要么出现“顶点全是0”之类的异常。
记住：最后一个参数是“字节偏移量”，不是CPU地址，更不是数组名。如果属性从数组起始处开始，填(void*)0即可；如果后面还有别的属性，要按前面所有属性占用的总字节数填写。
6.2 忘了绑定VAO，在Core Profile下直接报错
核心模式下不绑定VAO就调用glVertexAttribPointer，会触发GL_INVALID_OPERATION。但OpenGL的报错是“异步”的，glGetError()往往要等到后面某个时刻才会返回错误，所以这个错很容易被忽略。
排查方法很简单：在所有OpenGL调用之后加一个glGetError()检查，把错误码打印出来。GL_INVALID_OPERATION（1282）配合调用栈，就能基本定位到是哪一步出了问题。现在很多项目还会用glDebugMessageCallback把驱动日志输出到控制台，比手动查码高效得多。
6.3 EBO的索引与顶点数量对不上
如果索引数组里的某个索引值大于等于顶点总数，GPU会尝试读取不存在的顶点，轻则几何错乱，重则崩溃。这在动态生成索引时特别容易发生，尤其当你用std::vector动态扩容后忘记更新顶点总数、或者在做网格合并时索引没有正确偏移。
调试技巧：先用glDrawArrays代替glDrawElements，如果图形能出来说明VBO配置没太大问题，问题大概率出在EBO；然后再检查索引数组的最大值是否合理，比如一个顶点数为4的矩形，索引最大值不该超过3。肉眼检查不了超大数据时，写个循环取max即可。
6.4 着色器location和属性索引对不上
layout(location = 0) in vec3 aPos里的0，要和glVertexAttribPointer(0, ...)的第一个参数完全对应。如果着色器里写的是1，代码里配的是0，驱动会把颜色当成位置用，画出来的东西几乎没有例外是错的。
这种错误的特点非常明显：编译没问题、运行时也没报错、画面也不黑，但出来的几何就是不对。建议养成统一规范：位置属性固定用location 0，颜色用1，法线用2，UV用3，并且写一个简单的宏或常量类维护这些编号，不要裸写数字。
6.5 一句话排查顺序
我现在的习惯是，遇到渲染结果不对，按这个顺序排查：
- 先检查
glGetError有没有报错，有错先解决错。 - 用单色着色器替换原来的片元着色器，排除颜色数据或属性配置的问题。
- 把所有变换矩阵置为单位矩阵，直接用NDC坐标画，排除坐标变换问题。
- 换回
glDrawArrays，判断是不是索引的问题。 - 用RenderDoc抓一帧，直接看“Vertex Input”面板里VAO解析出来的数据是否和原始数组一致。
RenderDoc这个工具值得单独安利。它能直接显示每个顶点属性从哪个Buffer、哪个偏移、按什么stride读出来，读了哪些字节，甚至能看到着色器里的输入值。很多靠肉眼和打印日志排查一天的问题，在RenderDoc里一眼就看穿了。
6.6 面试爱问的点
搜索热词里有opengl面试题，说明很多人会拿这部分准备面试。围绕VBO/VAO/EBO，面试官最常问的维度大概是这几个：
- 三者的作用和区别是什么？能不能用一句话分别概括。
glDrawArrays和glDrawElements有什么区别，什么时候用哪个？glVertexAttribPointer的各个参数是什么意思？最后一个参数为什么看起来像指针？glBufferData和glBufferSubData有什么区别？usage里的STATIC、DYNAMIC、STREAM有什么区别？- 为什么现代OpenGL要求必须绑定VAO？
- 一个VAO可以绑定多个VBO吗？一个VBO可以被多个VAO引用吗？
我个人的答题思路是：先讲“数据放在哪、规则存在哪、索引怎么省”，分别点名VBO存数据、VAO存状态、EBO存索引；再补一个“一次draw call的数据流”把三者串起来。这一套讲完，对面的技术深度基本就立住了。实战中如果跟图形渲染打交道比较多，还会顺带延伸出实例化绘制时glVertexAttribDivisor和VAO的关系，这就属于加分项了。
我在实际编码里还有一个很强烈的体会：初学阶段不要急着写封装类、不要急着搞什么“Buffer管理器”，先用裸API把三角形和矩形的流程完整跑通。因为VBO、VAO、EBO这三个概念只有在“每次手动绑定、手动配置、手动解绑”的过程中，你才能真正理解状态机的执行顺序。等理解了再封装，你会发现自己写的接口会干净很多，也更容易避免把状态藏在某个角落导致莫名其妙的问题。
