不能直接传 vector 对象，因为 opengl 函数只接受裸指针，而 vector 是含元数据的结构体；必须用 vec.data() 获取元素起始地址，并确保 vector 生命周期覆盖缓冲区使用期。
直接传不行，必须取 data() 指针，且确保 vector 未被移动或销毁。
为什么不能直接传 vector 对象
OpenGL 的缓冲区上传函数（如 glBufferData）只接受裸指针（const void*），它不理解 C++ 容器对象。传 &vec 或 vec 本身会编译失败或导致未定义行为——因为 std::vector 是一个含指针和元数据的结构体，不是纯数据块。
- 常见错误：写成
glBufferData(GL_ARRAY_BUFFER, size, &vec, ...)—— 这传的是 vector 对象头地址，不是元素起始地址 - 正确做法永远是用
vec.data()（C++11 起）或&vec[0]（仅当!vec.empty()） - 若 vector 为空，
data()返回合法空指针，但glBufferData要求 size > 0 才有效；传 0 字节可能静默失败或触发GL_INVALID_VALUE
data() 返回的指针何时失效
std::vector 的连续内存只在未发生扩容、未被 move、未调用 shrink_to_fit() 或析构时保持有效。一旦失效，OpenGL 缓冲区内容就变成悬空数据——后续绘制可能黑屏、错位或崩溃，且无运行时提示。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 典型陷阱：把局部
vector传给glBufferData后立即返回，而 buffer 绘制发生在之后帧 —— 此时 vector 已析构，data()指向的内存已被回收 - 安全做法：确保 vector 生命周期 ≥ OpenGL 缓冲区生命周期；常用方案是成员变量持有 vector，或使用
std::unique_ptr<:vector>></:vector>显式管理 - 注意
push_back、resize、insert都可能触发 realloc，导致已有指针失效；上传前最好先reserve()或确认容量足够
数据类型对齐与 stride 必须匹配 GPU 要求
即使 data() 指针有效，若 vector 元素布局和 glVertexAttribPointer 中声明的 stride、type、normalized 不一致，GPU 会读错字节，结果不可预测。
- 例如：用
std::vector<float></float>存位置（x,y,z），每个顶点占 3×4=12 字节，则glVertexAttribPointer的stride必须为12，不能为0（除非是紧密排列单属性） - 若混存位置+颜色+纹理坐标，推荐用结构体 +
alignas(16)，并用offsetof计算偏移；避免用std::vector<:tuple>></:tuple>—— tuple 布局不可控，容易因 padding 错位 - 务必检查
sizeof(T)和 OpenGL 类型（如GL_FLOAT、GL_UNSIGNED_INT）是否匹配；误用GL_BYTE读float数据会导致全黑
要不要用 std::vector::shrink_to_fit() 上传前
不需要，反而有害。OpenGL 缓冲区上传后，GPU 会拷贝一份数据到显存，不再依赖 CPU 端内存。调用 shrink_to_fit() 可能触发 realloc，使刚传过的 data() 失效，但更关键的是：它不减少已上传数据，只影响后续 CPU 内存占用。
- 真正该做的是：上传完成后，如果 vector 不再需要，可主动
clear()+shrink_to_fit()释放 CPU 内存 - 若需动态更新（如骨骼动画顶点），应改用
glBufferSubData或映射缓冲区（glMapBufferRange），而非反复重建整个 vector 和 VBO - 频繁重建 vector +
glBufferData是性能杀手，尤其在主线程中；应预分配、复用、分帧更新
最易被忽略的一点：vector 的 data() 指针有效性完全独立于 OpenGL 缓冲区状态。你可以在上传后立刻 vec.clear()，只要确保之后不再用该指针——但很多人误以为“上传完 vector 就安全了”，其实上传只是拷贝动作，不延长 vector 寿命。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
