企业官网建设流程全解析

把神经网络丢进浏览器里训练，这件事在几年前听起来有点反直觉。CPU 上跑一个几层的全连接网络尚且要等结果，浏览器还能挤出多少性能？但如果你认真研究过 WebGL，会发现它本质上是一台披着渲染外壳的并行计算器。本文从一个可运行的角度拆解 WebGL 让神经网络在前向、反向、更新参数这一整条链路里真正跑起来的核心原理，先讲清楚“为什么能”，再给出一套能落地的最小实现与踩坑记录，适合对机器学习有基础、又想把训练搬到浏览器里的开发者。看完全文，你可以自己评估：是直接裸写 GLSL，还是把训练逻辑封装成自己能控制的工具。

1. 浏览器端训练不是噱头：从“能跑”到“值得跑”

浏览器端训练最大的价值，不是告诉你“WebGL 也能算矩阵乘法”，而是把训练这件事从服务器拉到用户终端。这听起来只是换了个地方跑代码，实际改变的却是数据的流向、产品的形态和交互的方式。

1.1 浏览器训练解决的三个痛点

第一个痛点是隐私和敏感数据。很多场景下，数据根本没有办法上传到服务器：医疗影像、财务资料、用户行为序列、公司内部文档，这些数据一旦离开本机，就需要面临脱敏、加密、传输链路等一系列额外处理。如果你的模型更新发生在浏览器本地，原始数据从头到尾不出设备，训练只是在本地 GPU 上完成，这就绕开了很多敏感数据外流的问题。我参与过一个内部工具类项目，前端需要根据用户本地的操作记录不断微调一个排序模型，数据留在浏览器里，后端只接收模型参数，这个架构让数据团队轻松了很多。

第二个痛点是零部署和零依赖。用户打开一个网页就能跑完整训练流程，不需要装驱动、不需要配 CUDA 环境、不需要理解 Python 包管理。传统的本地训练链路里，“环境没配好”能让新手卡住一整天，而浏览器把这一切都抹平了。对教学、技术分享、产品 Demo 来说，这种可传播性极其重要。你发一个链接过去，对方在手机上都能看到训练曲线实时跳动，这种体验是服务器方案很难给的。

第三个痛点是交互式调试。浏览器天然有 UI，可以把权重分布、梯度范数、中间层特征图直接画在画布上。我在做一个图像分类演示时，把每个 epoch 的损失曲线和权重直方图并排显示，调整学习率后立刻能在响应中看到梯度变化。这种即时反馈让我对训练过程的理解比在终端里看日志要直观得多。对于想入门机器学习的同学来说，浏览器训练是几乎零门槛的“可观察试验台”。

1.2 适用边界：哪些场景不适合浏览器训练

这里必须泼一盆冷水。浏览器训练不适合所有任务，它更适合参数规模可控、数据量不大、对隐私或交互有强需求的场景。一个几十亿参数的大模型，即使不考虑加载时间，纹理布局这一关就先过不去——GPU 显存有限，纹理尺寸也有限。上万条样本的全量训练同样不适合，数据从网络或本地文件读入 TypedArray，再由 CPU 写到纹理，这个 I/O 过程仍然存在，并没有因为“在浏览器里跑”就凭空消失。

我自己在项目里的判断标准是：参数量在百万量级以下、单次训练数据在几百 MB 以内、训练时长可以接受在几秒到几分钟，浏览器训练就是可选方案。再往上走，还是把数据传到服务器更现实。浏览器训练不是一个“替代服务器训练”的银弹，而是一个新的交互层和分发层。它的意义在于把训练能力带到用户面前，让个性化、私密性、即时反馈成为可能。

2. WebGL 真相：一块挂在浏览器里的并行计算阵列

要理解 WebGL 为什么能训练神经网络，先得放下“它是用来画图的”这个思维定式。渲染只是 WebGL 的外在形式，它背后是一个能并行处理海量像素的计算阵列。

2.1 GPU 的并行模型与片元着色器

GPU 的核心优势是并行。它内部有成百上千个计算单元，SIMT 模式下这些单元同时执行同一个程序，但操作的是不同的数据。渲染管线处理三角形时，会把每个三角形覆盖到的像素拆成独立任务，每个像素执行一遍片元着色器。这些像素之间没有依赖，所以可以大规模并行。神经网络里的矩阵乘法恰好也有类似特征：输出矩阵的每个元素只由输入矩阵和权重矩阵决定，相互之间没有依赖，天然适合拆成一个个像素任务。

生活中的类比是：你有一万道完全一样的选择题，每道题只有数字不一样。与其找一个聪明人从头做到尾，不如找一万个人每人做一道题。WebGL 干的就是这件事，片段着色器就是给每个职位发的那道题，庞大的矩阵运算被切割成无数独立的小任务。这也是为什么浏览器端的神经网络训练能跑出远超纯 JavaScript 的速度——它实际动用了 GPU。

片元着色器的输出默认是屏幕像素，但我们可以通过帧缓冲对象把它改写到一张纹理上。渲染一遍、写入一张纹理、再作为下一层的输入读取，这就构成了一次计算。渲染循环在这里不再是为了“显示画面”，而是为了“执行计算”，画面上什么都看不见，但数据已经在这些纹理之间流动起来。

2.2 纹理即张量：矩阵如何装进 RGBA

WebGL 纹理本质是一块二维的 RGBA 数组，每个像素有 R、G、B、A 四个分量。这意味着一个像素最多能存储 4 个浮点数。如果你要把一个 m×n 的矩阵存进纹理，最简单的布局是把矩阵的行映射到纹理的 Y 方向，列映射到 X 方向，矩阵的第 i 行第 j 列存放在纹理坐标 (j, i) 处。

更进一步，你可以把同一行里相邻的 4 个数打包进一个像素的 RGBA 分量，纹理宽度瞬间变成原来的四分之一。这对节省纹理空间和减少渲染尺寸非常有效，着色器里一次读取四个分量，可以在同一时间处理四个输出元素。这种“一次计算四个值”的打包技巧，是很多浏览器端深度学习库性能提升的关键之一，也是裸写 WebGL 时值得自己实现的操作。

需要注意纹理的尺寸有上限，一般桌面端是 4096 或 8192，移动端常常是 2048 或更小。所以大矩阵不能直接塞进一张纹理里，而是要规划布局：要么把矩阵按行切成多段，把每一段排成独立的纹理；要么用 RGBA 打包减少宽度；要么干脆把矩阵重排成二维分块。数据布局直接影响后续所有着色器的读写坐标，这是浏览器端训练里最重要也最容易被忽略的抽象。

2.3 着色器即算子：神经网络层的 GLSL 化

在 WebGL 里，一个神经网络层就是一个片元着色器。输入层的激活值存进一张纹理，权重存进另一张纹理，着色器对每个输出像素执行相同的循环累加逻辑，最后把结果写入输出纹理。激活函数、池化、归一化、损失函数，这些都可以写成对应的着色器。一个多层网络就是一连串的着色器程序和纹理传递。

所以“神经网络在浏览器里跑起来”的本质，是把张量运算的数据流映射成纹理数据流，把算子映射成着色器。前向传播是红色数据从输入纹理流向一层层输出纹理，反向传播是绿色梯度从损失纹向往回流动，参数更新是权重纹理原地算术操作。着色器之间没有共享内存，但网络结构天然是管道式的，每层只依赖上一层的输出和本层的参数，这种管道式结构正好吻合 WebGL 的渲染到纹理流程。

有些框架会自动帮用户完成这个过程：你定义一个层，它生成对应的 GLSL 代码；你调用 fit，它管理所有纹理和缓冲。但那层抽象像个黑盒，一旦出现问题，你根本不知道是 GLSL 写错了、纹理布局对不上、还是帧缓冲对象没绑定对。这也是我坚持自己裸写一套最小训练循环的原因，只有亲手跳过这些坑，才能真正掌握浏览器端训练的底层机制。

2.4 浮点纹理与精度限制

WebGL 纹理默认是 8 位无符号整数，这对神经网络完全不可用。必须通过浮点纹理扩展来支持真正的 float 类型。WebGL1 下需要获取 OES_texture_float 扩展，WebGL2 下需要 EXT_color_buffer_float 扩展。这些扩展并不是所有设备都支持，尤其是移动端，很多浏览器只支持半浮点纹理，或者根本不支持浮点渲染，导致你的着色器写入了纹理，但结果永远不会更新。

还有精度限定符的问题。在片元着色器里可以声明 precision highp float，但移动端 GPU 的绝大多数片元着色器只保证 mediump 精度，有些旧设备甚至连 highp 都不支持。float 的表示范围小、有效位数少，训练中一旦出现较大的中间值，损失函数和梯度就很容易变成 NaN。所以在浏览器端训练里，输入数据的归一化不是建议，而是必修课。把所有特征缩放到 0 附近，把学习率设置得比在服务器训练时更谨慎，能省掉大量精度导致的诡异问题。

3. 手把手实现一个浏览器端训练管线

理论说完了，接下来看最小实现。这里用一个单层全连接网络做例子，目的是把整个链路走通：数据、权重、损失、梯度、更新、迭代。看懂这一套，扩展到多层网络和卷积只是加着色器的问题。

3.1 先想清楚画布布局：矩阵与纹理的映射关系

假设输入向量是 x，形状 1×K；权重矩阵是 W，形状 K×N；输出向量是 y = xW，形状 1×N。输入纹理宽度设为 K，高度为 1；权重纹理宽度设为 N，高度为 K；输出纹理宽度设为 N，高度为 1。RGBA 四个分量先不用，所有数据都放在 R 通道，便于理解。

之所以把权重纹理的高度设为 K、宽度设为 N，是为了让着色器在计算第 j 个输出神经元时，能垂直读取同一列的数据。纹理的 Y 坐标表示输入维度，X 坐标表示输出维度，这样第 (x, y) 个纹素正好对应 W[y, x]。输入向量只有一行，所以读取时 Y 坐标始终是 0.5 的归一化位置。这个布局关系如果搞反了，后面的结果全乱，排查起来极痛苦。

实际项目里输入常常是批量的。一个 batch 有 B 个样本，每个样本是 1×K，那就可以把输入纹理布局成 B×K，输出纹理布局成 B×N。权重纹理保持 K×N 不变，因为所有样本共享同一套权重。着色器里用 gl_FragCoord.y 判断当前算的是哪个样本，再用它取输入纹理对应行的值，就能实现天然的批量并行。

3.2 数据进去：浮点纹理与扩展检查

创建浮点纹理之前，先检查扩展。下面这段 JavaScript 代码展示了创建 WebGL 画布、获取扩展、创建纹理并把数据写入纹理的完整步骤。

const canvas = document.createElement('canvas'); const gl = canvas.getContext('webgl2'); if (!gl) { // 降级到 webgl1 或提示不兼容 throw new Error('WebGL2 not supported'); } const floatRenderable = gl.getExtension('EXT_color_buffer_float'); const floatTexture = gl.getExtension('OES_texture_float'); if (!floatRenderable || !floatTexture) { throw new Error('Float render texture not supported'); } function createFloatTexture(width, height, data) { const tex = gl.createTexture(); gl.bindTexture(gl.TEXTURE_2D, tex); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.NEAREST); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.NEAREST); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_S, gl.CLAMP_TO_EDGE); gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_T, gl.CLAMP_TO_EDGE); gl.texImage2D( gl.TEXTURE_2D, 0, gl.RGBA32F, width, height, 0, gl.RGBA, gl.FLOAT, data || null ); return tex; }

这里最关键的细节是纹理过滤必须设置成 NEAREST，不能使用线性过滤。线性过滤会对相邻像素做插值，那两个矩阵元素的边界会被平滑掉，数学计算就变成了一种“混沌模糊”，训练永远不可能收敛。另一个重要设置是 CLAMP_TO_EDGE，防止采样坐标越界后产生重复边缘值，那种情况在矩阵运算中会造成莫名的计算结果偏移。

3.3 前向传播：把矩阵乘写成片元着色器

前向传播的片元着色器，内部就是一次标准的矩阵乘法循环。每个输出像素代表输出向量中的一个神经元，它遍历 K 维输入，累加 x[k] 乘以 W[k, j]。

precision highp float; uniform sampler2D uInput; // 1xK 输入纹理 uniform sampler2D uWeight; // KxN 权重纹理 uniform float uK; uniform float uN; void main() { float sum = 0.0; vec2 inputUV = vec2(0.5 / uK, 0.5); // 输入向量只有一个样本 for (float k = 0.0; k < uK; k += 1.0) { float x = texture2D(uInput, vec2((k + 0.5) / uK, 0.5)).r; float w = texture2D(uWeight, vec2((gl_FragCoord.x + 0.5) / uN, (k + 0.5) / uK)).r; sum += x * w; } gl_FragColor = vec4(sum, 0.0, 0.0, 1.0); }

几个坐标计算值得解释清楚。texture2D 的坐标是归一化的，像素中心的坐标需要加上 0.5 再除以纹理宽度，否则会采到像素边缘。gl_FragCoord.x 是当前输出像素的整数坐标，对应输出向量第 j 个神经元。权重纹理的 X 方向坐标用 gl_FragCoord.x，Y 方向坐标用当前循环变量 k，就能取到 W[k, j]。这个“当前输出像素决定权重列位置”的思路，是理解所有 WebGL 神经网络层的关键。

在 WebGL2 里还可以用 texelFetch 直接按整数坐标读纹理，不用归一化坐标，逻辑上更清晰，性能也更好。但 texelFetch 要求纹理格式支持整数采样，浮点纹理在多数设备上可以，移动端兼容性要测过才知道。我自己的习惯是先用 texture2D 把网络跑通，再针对瓶颈层换 texelFetch。

3.4 反向传播与权重更新：梯度也是像素

反向传播的核心是根据输出梯度计算权重梯度。对于简单全连接层，权重 W[k, j] 的梯度是输入 x[k] 与输出梯度 dy[j] 的乘积。因为梯度矩阵的形状和原权重矩阵完全一致，所以梯度纹理的布局可以和权重纹理保持一致。

function runPass(program, inputTex, outputTex, width, height, extraUniforms) { gl.useProgram(program); gl.activeTexture(gl.TEXTURE0); gl.bindTexture(gl.TEXTURE_2D, inputTex); gl.uniform1i(gl.getUniformLocation(program, 'uInput'), 0); for (const [name, value] of Object.entries(extraUniforms)) { const loc = gl.getUniformLocation(program, name); if (typeof value === 'number') gl.uniform1f(loc, value); else gl.uniform2f(loc, value[0], value[1]); } gl.bindFramebuffer(gl.FRAMEBUFFER, fbo); gl.framebufferTexture2D( gl.FRAMEBUFFER, gl.COLOR_ATTACHMENT0, gl.TEXTURE_2D, outputTex, 0 ); gl.viewport(0, 0, width, height); gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); }

这个 runPass 函数是整个训练引擎里最核心的工具函数。它接收一个着色器程序、一张输入纹理、一张输出纹理，把输入绑定到采样器，再让 GPU 执行一次全屏绘制，从而把计算结果写进输出纹理。损失的反向传播、梯度计算、权重更新，本质上都是一次又一次的 runPass 调用，区别只在于绑定的纹理组合不同。

顺着这个思路，反向传播的梯度着色器会读取输出梯度纹理和输入激活纹理，输出一张与权重纹理形状相同的梯度纹理。具体来说，对输出像素 (j, k)，它计算的梯度值是 dy[j] × x[k]。这里的 dy 来自损失函数对输出向量的导数，如果是 MSE 损失，dy 就是预测值减去真实值，可以写成一个单独的着色器，读取输出纹理和标签纹理，输出梯度纹理再喂给下一层。

权重更新则更简单：新权重等于旧权重减去学习率乘以梯度。这是一个逐像素操作，着色器里只有一行乘法和加法。但要注意，这个操作会同时读写同一张权重纹理吗？如果直接这样做，所有像素都在并行执行，彼此之间不知道读写顺序，结果会产生不可预知的竞争。所以更新过程需要一对双缓冲纹理：一张保存旧权重，一张保存新权重，swap 之后下一轮迭代使用新权重。

3.5 双缓冲训练循环：帧缓冲对象的正确用法

双缓冲是浏览器端训练中绕不开的概念。它的原理很简单：设定两张纹理，一张作为输入，一张作为输出；这一轮把输入纹理读进着色器，把结果写入输出纹理；下一轮开始前交换两者，输出纹理变成输入纹理，旧输入纹理变成新输出。乒乓交换避免了在同一纹理上读写造成的竞争。

let curWeight = createFloatTexture(N, K, initData); let nextWeight = createFloatTexture(N, K, null); for (let epoch = 0; epoch < 100; epoch++) { // forward: x -> yPred runPass(forwardProgram, inputTex, yPredTex, N, 1); // loss gradient: dMSE / dy runPass(lossGradProgram, yPredTex, labelTex, dyTex, N, 1); // weight gradient: x^T * dy runPass(bwdProgram, dyTex, inputTex, gradTex, N, K); // update: W -= lr * grad runPass(updateProgram, curWeight, gradTex, nextWeight, N, K); // swap const tmp = curWeight; curWeight = nextWeight; nextWeight = tmp; }

注意这里绑定 FBO 的逻辑：每次 runPass 都重新把输出纹理挂到帧缓冲对象的颜色附件上，所以 fbo 只需要创建一次，重点是 framebufferTexture2D 必须每次调用。有些实现会为每个输出纹理各建一个 FBO，性能差别不大，但内部管理起来更费内存。我习惯只用一个 FBO 反复重绑，省纹理也省对象。

收尾时如果想看 loss，不能每步都用 readPixels 把结果读回 CPU，那样成本太高。正确做法是单独跑一个 reduce 着色器，把一维输出向量规约成一个标量，写入一张 1×1 纹理，再对这张 1×1 纹理执行一次 readPixels。这样损失值每轮都能拿到，但读取的只是一个像素，代价可以接受。

4. 实战踩坑：浏览器训练里的疑难杂症排查

理论上链路是通的，现实里每一环都可能悄悄出错。我把自己在浏览器端训练中实际踩过的坑整理成下面这些类别，每一条都对应着一次真实的排查经历。

4.1 loss 不降或变成 NaN：精度陷阱

最让人头疼的问题是网络不收敛，指数 loss 直接变成 NaN，或者从头到尾一动不动。这类问题里，输入数据和权重初始化往往是第一嫌疑。输入值如果不在 0 附近，比如数值范围是 100 到 1000，前向传播的累加和很容易超出 float 的精度范围。尤其是在移动端，mediump 的有效位数可能只有 10 位左右，大数加小数时直接丢精度，梯度算出来全是零。

我处理这类问题的标准流程是：先把输入归一化到 [-1, 1] 或 [0, 1]，把权重初始化范围缩小到 ±0.01，学习率从很小的值比如 0.001 开始。如果还有 NaN，就在更新着色器里加梯度裁剪。裁剪逻辑并不复杂，如果梯度绝对值超过阈值就缩小到阈值，防止一次更新把参数推出有效范围，这个操作在浏览器端几乎零成本，却能让训练稳定很多。

还需要警惕的是着色器精度声明。WebGL1 下很多设备默认的片元着色器精度是 mediump，即使你声明了 highp，某些显卡也会静默降级。所以我的代码里会用一个精度探测着色器，跑一次输出一个统一值，然后把这个值回读到 CPU，检查误差是否在可接受范围内。这一点在移动端尤其不能省略。

4.2 矩阵尺寸超限与分块策略

纹理尺寸限制是浏览器训练里最物理性的约束。一次做个 K=128、N=128 的全连接层毫无压力，但如果输入是 512×512 的图片，第一层卷积核输出又是 512 个通道，那权重纹理可能直接超过 MAX_TEXTURE_SIZE。

遇到这种情况有几种处理方式。最简单的是把大矩阵按行切成若干块，每一块作为一个独立纹理，跑多次着色器，再把结果拼接回一张输出纹理。这个过程逻辑复杂，但能立刻打破尺寸限制。另一种方式是 RGBA 打包，把四个相邻的矩阵元素放进一个像素的四个通道，纹理宽度直接缩到四分之一，这是我在实际项目里最常用的一招。

还有一种边界情况是 K 维度过大，导致单个着色器里的循环次数非常多，GPU 执行时间指数上涨。这种情况下，可以改成多 pass 累加：把输入维度切分成几段，每段跑一次矩阵乘法，再把部分和相加。这相当于把一个长循环拆成几个短循环，每次循环都停留在 GPU 的并行处理舒适区内，整体吞吐量往往更高。

4.3 readPixels 的性能黑洞

很多初次接触 WebGL 训练的人都会不由自主地每轮把权重、激活值、loss 全部读回 JavaScript。readPixels 是一个同步调用，它会打断 GPU 的流水线，强制让 GPU 等 CPU，再把数据从显存拷贝到内存。频繁调用 readPixels，浏览器训练直接退化成一连串昂贵的同步等待，速度可能比纯 CPU 还慢一个量级。

我的经验是：训练过程中，只在可接受的时间点读 loss，其他中间结果一律留在 GPU 上。如果你想观察建模质量，可以每 N 个 epoch 读一次，然后画在 canvas 上。如果必须读取权重做持久化，就训练结束后一次性读整张纹理，而不是逐像素读。WebGL2 下还可以用像素打包缓冲区把拷贝异步化，让 GPU 在读回之前继续执行后续计算，这是更先进的优化手段。

4.4 移动端碎片化与降级方案

移动端是 WebGL 训练最大的不确定因素。不同厂商的 GPU 驱动对浮点纹理的支持差异极大，有些支持 OES_texture_float 但不支持浮点渲染，有些只响应 EXT_color_buffer_float 却对 RGBA32F 格式报错。我建议在启动训练前做一次全面的环境探测，而不是等到训练开始后再报错。

降级方案的思路是分层：有浮点纹理就上 GPU 训练；只有半浮点纹理就尝试半精度训练，但要做好精度下降的准备；什么都不支持就直接降回 CPU 计算。在 JavaScript 里写一个简单的全连接层并不难，几百条数据足够撑住一个演示，虽然慢，但功能完整。这样用户至少能跑通整个流程，而不是看到一片黑屏。

移动端还有一个容易忽略的问题是功耗和发热。长时间满载运行 GPU 会导致手机发烫、降频，训练速度会越来越慢。如果有移动端部署需求，我的建议是控制训练步数，减少每次迭代的纹理尺寸，并提供暂停按钮，让用户自己决定何时暂停。

4.5 问题速查表

很多问题表面上千奇百怪，排查到最后都是几个固定原因。下面这张表是我反复用到的速查清单，遇到类似现象时可以直接按图索骥。

这张表解决了我很多次“雾里看花”的排查过程。

5. 优化与选型：裸写 WebGL 还是用封装框架

当你把最小管线跑通之后，下一步自然是优化和选型。性能优化集中在着色器层面，而“自己写还是用框架”决定了你后续能掌控多少细节。

5.1 着色器级优化习惯

GPU 并行计算最怕分支发散。同一批像素在执行着色器时，只要出现 if 分支，硬件就必须把走不同分支的线程分开执行，然后再汇合。这个“汇合”过程会消耗额外的周期，如果你的代码里有很多“if (x > 0.5) 做 A 否则做 B”的逻辑，性能会明显下降。我通常在着色器里用 step 函数或 mix 函数代替分支，让所有像素都执行同一条指令路径，只是通过参数让部分像素的结果不生效。

循环次数也是一个需要控制的因素。GPU 的着色器循环是动态的，但驱动编译器会尽量展开循环，展开太大会导致寄存器压力激增。我把循环次数限制在 256 以内，超过 256 就考虑用多次 pass。另一个朴素但实用的优化是，把不会变化的 uniform 值在进入循环之前缓存到局部变量里，避免每次循环重复从 uniform 内存加载。

纹理采样是另一个容易被忽视的瓶颈。矩阵乘法中，如果两个像素访问的纹理坐标跨度很大，GPU 的纹理缓存命中率会下降。合理的数据布局姿势是让相邻像素尽可能访问相邻纹素。比如线性层输出 N 维度很大时，把权重纹理的 X 维度对应输出维度，就能让同一行的相邻像素读取权重纹理连续的列，缓存命中率显著提高。

5.2 纹理复用与内存管理

每一次 createTexture、texImage2D 都涉及内存分配和初始化，千万别在训练循环里频繁创建新纹理。一个训练步骤里需要前向输出、梯度、中间激活值，这些纹理的形状基本固定，完全可以在训练开始前一次性创建好，然后循环复用。纹理对象本身不便宜，但它不要求你每轮都重新建，只要内容可以被覆盖更新就行。

帧缓冲对象同理。一个 FBO 创建一次，然后通过 framebufferTexture2D 在每次 runPass 时绑定到不同纹理。重新绑定纹理的开销远小于新建 FBO 的开销。内存碎片的问题虽然 JavaScript 层面不明显，但 GPU 显存分配仍然需要谨慎，纹理池方案能有效控制显存占用，也能避免训练过程中频繁 GC 导致的主线程卡顿。

5.3 框架封装帮我们解决什么

开源社区已经有若干成熟的浏览器端机器学习方案，它们的主要工作就是封装纹理管理、着色器生成、自动微分、图优化和后端切换。你写一句 model.add(layer)，它背后会生成一堆 GLSL 程序，自动管理所有纹理生命周期，甚至会在不支持 GPU 时自动降级回 CPU。

用这些框架的最大优点是省心，尤其是自动微分，它把反向传播从“手工推导公式 + 手写着色器”中解放出来，让你能快速搭建复杂网络。代价则是调试困难。框架生成的着色器是一大段编译产物，出问题时你很难直接在 GLSL 层定位。我的建议是：如果你想快速验证模型效果，用框架；如果你在做底层原理研究，或者需要极致性能，裸写 WebGL 更可控。两条路我都走过，裸写一遍让我后来用框架时的调试轻松很多。

5.4 WebGPU 会改变浏览器训练的格局吗

WebGPU 是浏览器 GPU 计算的新一代方案，它引入了 compute shader 和 storage buffer，可以直接把数据当成普通数组读写，不再需要纹理和帧缓冲对象这一整套“改装工具”。从原理上说，WebGPU 给出的才是 GPU 通用计算本来该有的样子，精度和性能上限都优于 WebGL，代码也直观得多。

不过从我的实际观察来看，WebGL 在未来很长一段时间里仍然是兼容性最稳的方案。它被所有主流浏览器支持，扩展检查过后几乎能覆盖所有设备；而 WebGPU 的 API 稳定性和驱动适配还在持续完善中。如果你的项目面向广泛互联网用户，WebGL 仍是保守而可靠的选择。如果是新项目的预研，或者面向的是确定支持 WebGPU 的受众，那完全可以提前切换到更顺手的计算模型。

最后分享一个小习惯

所有做浏览器端训练的人，最终都会积累一套自己的排障习惯。我最想重点留给你们的是：无论你用框架还是裸写 WebGL，先在 CPU 上写一份参考实现，固定随机种子，把每一层的前向输出打印出来。GPU 版本只要结果不一致，就逐层对比，很快能定位到是布局问题、着色器问题还是精度问题。我第一次搭整套管线时，以为遇到的问题都是精度导致的，最后发现只是 UV 坐标少加了半个像素。如果没有 CPU 参考实现，这个问题不知道还要调多久。希望这篇关于 WebGL 训练原理的拆解，能让你少踩一些相似的坑。