WebGL是直接调用GPU的底层接口，需手动管理着色器、缓冲区、矩阵变换和帧循环；动画逻辑应置于顶点着色器中通过uniform传时间实现GPU并行计算，避免CPU逐顶点运算；动态纹理更新须用texImage2D并确保绑定与格式一致；混合2D时需正确配置alpha及合成方式。
WebGL 不是用来“增强” HTML5 动画的装饰工具，它是绕过 canvas 2D 渲染管线、直接调用 GPU 的底层接口。想靠它提升动画性能，得先接受：你不再写 requestAnimationFrame + ctx.fillRect，而是写着色器、管理缓冲区、处理矩阵变换。
WebGL 动画必须手动控制帧循环，不能依赖 CSS 或 canvas 2D 自动机制
HTML5 动画常依赖 CSS animation 或 canvas 2D 的简单绘图循环，但 WebGL 没有内置“动画系统”。所有帧更新都由你通过 requestAnimationFrame 驱动，且每一帧必须显式重绘：
-
gl.clear()必须每帧调用，否则上一帧残留像素会叠加 -
gl.drawArrays()或gl.drawElements()必须在每次循环中执行，不调用就不会出图像 - 状态（如绑定的纹理、着色器程序）不会自动重置，需手动管理或复位
顶点着色器里做动画比 JS 算位置更高效，但必须用 uniform 或 attribute 传时间
把动画逻辑写在 JavaScript 里再传顶点坐标，是常见误区——这等于 CPU 计算每个顶点，再上传 GPU，毫无性能优势。真正高效的路径是把时间变量传进着色器，在 GPU 上并行计算：
attribute vec2 a_position;
uniform float u_time;
void main() {
vec2 offset = vec2(sin(u_time * 0.5), cos(u_time)) * 0.2;
gl_Position = vec4(a_position + offset, 0.0, 1.0);
}-
u_time是 JS 每帧用gl.uniform1f(timeLoc, performance.now() / 1000)更新的 uniform - 避免在顶点着色器里调用复杂函数（如
pow多次嵌套），移动端驱动可能编译失败 - 若需逐顶点不同节奏，改用
attribute float a_phase+ uniform 时间，而非 JS 算好再上传数组
用 texImage2D 动态更新纹理实现逐帧动画时，注意格式与绑定顺序
想用 WebGL 播放序列帧（比如 sprite sheet 切割或视频帧），不能像 texImage2D 把新像素数据推到 GPU 纹理对象上：
立即学习“前端免费学习笔记（深入）”；
- 每次更新前必须确保目标纹理已绑定：
gl.bindTexture(gl.TEXTURE_2D, texture) - 传入的像素数据类型（
gl.UNSIGNED_BYTE）、格式（gl.RGBA）、尺寸（宽高需是 2 的幂，或开启gl.TEXTURE_WRAP限制）必须和首次创建时一致 - 若从
或读帧，要等其readyState === 4（视频）或drawImage完成后再调用texImage2D，否则传空数据
混合 2D 和 WebGL 时，canvas 的 alpha: false 可能导致透明合成失效
很多项目想在 WebGL 画布上叠加 HTML 文字或 2D 图形，结果发现文字发虚、半透明层错乱——根源常是 canvas 创建时没配对 alpha 行为：
- 若 WebGL 需透明背景（如覆盖在网页其他元素上），初始化时必须设
{ alpha: true }，且每帧gl.clearColor(0,0,0,0) - 但此时若用
ctx.drawImage(canvas, ...)把 WebGL 画布当图片源，Chrome 默认按 premultiplied alpha 解析，而 Firefox 可能不，造成跨浏览器差异 - 稳妥做法：用
gl.readPixels()+ImageData手动合成，或用OffscreenCanvas（仅现代浏览器支持）隔离渲染流程
真正卡住人的从来不是怎么画一个旋转三角形，而是纹理单位没激活、帧缓冲没检查 gl.checkFramebufferStatus、或者 uniform location 返回 -1 却没查错。WebGL 的“增强”，只对愿意直面这些细节的人生效。
