各位同学，大家好！欢迎来到今天的“Web 图形学进阶实战”讲座。我是你们的老朋友，一个在 React 和 WebGL 边缘疯狂试探的资深工程师。
今天我们要聊的话题，听起来可能有点枯燥，甚至有点反直觉。你们习惯了 JavaScript 的垃圾回收机制（GC），习惯了 React 的自动内存管理，对吧？但是，当我们把视线从 CPU 的内存（RAM）移开，投向那块昂贵的显卡显存（VRAM）时，情况就完全变了。
今天，我们要深入探讨一个极其严肃的话题：React 与 GPU 资源销毁协议。
听着，这可不是在讲什么高深的图形学渲染管线，也不是在讲 Shader 编程。我们讲的是“人命关天”的代码。如果你的纹理贴图（Textures）和缓冲区（Buffers）在组件卸载时没有被正确销毁，你的应用不仅会变卡，而且会在不知不觉中让你的浏览器变成一块砖头。
来，把你们手里的咖啡放下，咱们开始吧。
第一章：为什么 React 的“垃圾回收”在 GPU 面前会失效？
首先，我要打破一个很多人的幻想。
在普通的 JavaScript 开发中，当你不再需要一个对象时，你不需要去手动删除它。React 的 useEffect 清理函数，或者 React 的垃圾回收器会帮你搞定。但在 GPU 的世界里，没有垃圾回收。
这就像什么？这就像你租了一间房子（显存）。如果你不退房（销毁资源），房东（GPU）是不会把房子收回去的。相反，他会把你赶出去，把你的家具（纹理）扔在街上。而且，如果你不退房，房东还会把你列入黑名单，以后再也不把房子租给你（浏览器崩溃或 WebGL 上下文丢失）。
显存是有限的。通常情况下，一块显卡也就 8GB、12GB 或者 24GB。如果你在 React 组件里创建了一个 4K 的纹理，又创建了一个 4K 的环境贴图，再加一个 4K 的法线贴图……那是 12GB 的 VRAM 被占用了。如果你的应用有 10 个这样的组件，而且它们卸载了，但资源没有释放，那么显存瞬间就被填满了。
React 的 useEffect 返回的清理函数，就是你的“退房协议”。但是，如果你在协议里写得不好，房东（GPU）会非常生气。
第二章：基础协议——清理函数的正确姿势
让我们先从一个最基础的例子开始。假设你有一个 ImageViewer 组件，用来展示一张 3D 模型的高清纹理。
import React, { useEffect } from 'react';
import * as THREE from 'three';
const ImageViewer = ({ imageUrl }) => {
useEffect(() => {
console.log('组件挂载，开始加载纹理...');
// 1. 创建纹理
const loader = new THREE.TextureLoader();
const texture = loader.load(imageUrl);
// 2. 假设我们做了一些处理
texture.colorSpace = THREE.SRGBColorSpace;
texture.minFilter = THREE.LinearFilter;
// 3. 绑定到某个 Canvas 或者只是存在内存里
// ...
// 4. 返回清理函数
return () => {
console.log('组件卸载，正在销毁资源...');
// 关键步骤：销毁纹理
if (texture) {
texture.dispose();
// 这一步至关重要：防止内存泄漏
// 虽然 dispose() 会释放 GPU 资源，但有时我们需要手动断开 JS 引用
texture.image = null;
texture.source = null;
}
if (loader) {
loader.dispose();
}
};
}, [imageUrl]); // 依赖项
return <div>图片查看器正在运行</div>;
};看起来很简单，对吧？但这里面藏着几个坑。如果你只是简单地调用 texture.dispose()，有时候事情并没有完全结束。
第三章：异步地狱与“幽灵资源”
很多同学喜欢用异步操作来处理资源加载。比如，在组件卸载的时候，如果资源还在加载中，你会怎么做？
通常的做法是：
useEffect(() => {
const texture = new THREE.Texture();
const image = new Image();
image.src = 'https://example.com/image.jpg';
image.onload = () => {
texture.image = image;
texture.needsUpdate = true;
};
return () => {
// 组件卸载了，清理一下
texture.dispose();
image.src = ''; // 试图停止加载
};
}, []);警告！ 这里有一个巨大的陷阱。
如果 image.onload 的回调比组件的卸载清理函数晚执行了 1 毫秒怎么办？或者晚执行了 1 秒怎么办？
当组件卸载时，return () => { ... } 执行了。它调用了 texture.dispose()。这会告诉 WebGL：“嘿，这块显存你可以回收了。”
但是，如果在清理函数执行后的几毫秒内，image.onload 触发了。它看到 texture.image 还在（因为我们没有在清理函数里把它设为 null，或者因为我们只是调用了 dispose，但没有阻止回调执行），于是它尝试更新纹理。
这时候会发生什么？WebGL 报错！
而且更糟糕的是，那个纹理可能已经被标记为可被回收了，但回调还在尝试操作它。这会导致你的渲染循环崩溃，或者产生极其诡异的渲染错误。
正确的做法：使用一个“取消标志”或者“Ref”。
useEffect(() => {
let isMounted = true; // 这是一个标志位，表示组件还活着
const texture = new THREE.Texture();
const image = new Image();
image.src = 'https://example.com/image.jpg';
image.onload = () => {
if (!isMounted) {
console.log('组件已经卸载，忽略加载完成回调');
return;
}
// 只有组件还活着才处理
texture.image = image;
texture.needsUpdate = true;
};
return () => {
isMounted = false; // 组件卸载，设置标志位
// 立即断开引用
texture.image = null;
texture.dispose();
// 尝试取消图片加载（这取决于浏览器实现，通常无法完全取消网络请求）
image.src = '';
};
}, []);这就是协议的第一条铁律：在清理函数中，不仅要销毁 GPU 资源，还要立即切断 JS 对资源对象的引用，并阻止异步回调继续操作这些资源。
第四章：React Three Fiber (R3F) 的特殊协议
如果你用的是 react-three-fiber，情况会稍微复杂一点，但也更优雅。R3F 封装了很多底层逻辑，但并不代表你可以高枕无忧。
1. useFrame 里的陷阱
useFrame 是 R3F 最常用的钩子。很多新手喜欢在 useFrame 里创建资源，或者在 useFrame 里引用了外部资源却不清理。
import { useFrame } from '@react-three/fiber';
function BadComponent() {
let texture;
useFrame(() => {
if (!texture) {
texture = new THREE.Texture(); // 每一帧都在创建？这是灾难！
}
// ... 使用 texture
});
// 组件卸载时，谁来清理 texture？
// useEffect 的清理函数在这里面拿不到这个 texture 变量
// 因为 texture 是在 useFrame 闭包里定义的。
}修正方案：
如果你必须在 useFrame 里操作资源，你必须确保资源是在组件顶层定义的，而不是在 useFrame 内部。
import { useFrame } from '@react-three/fiber';
function GoodComponent() {
const texture = useMemo(() => new THREE.Texture(), []);
useFrame(() => {
// 使用 texture
});
useEffect(() => {
return () => {
texture.dispose();
};
}, [texture]);
}2. 事件监听器
在 R3F 中，我们经常使用 onClick、onPointerOver 等。这些事件处理函数会绑定到 3D 物体上。当你卸载组件时，这些处理函数必须被移除，否则它们依然会持有对组件内部变量的引用（闭包陷阱）。
function MyMesh() {
const [hovered, setHovered] = useState(false);
// 正确的做法：在清理函数中移除事件监听
useEffect(() => {
// 假设我们通过 ref 获取到了 mesh
const mesh = meshRef.current;
const handlePointerOver = () => setHovered(true);
const handlePointerOut = () => setHovered(false);
mesh.addEventListener('pointerover', handlePointerOver);
mesh.addEventListener('pointerout', handlePointerOut);
return () => {
mesh.removeEventListener('pointerover', handlePointerOver);
mesh.removeEventListener('pointerout', handlePointerOut);
};
}, []);
return <mesh ref={meshRef} />;
}注意，这里的 handlePointerOver 和 handlePointerOut 是在 useEffect 里定义的，所以它们属于 useEffect 的清理函数作用域。当组件卸载时，React 会自动运行清理函数，移除这些监听器。
3. useLoader 的缓存机制
这是 R3F 中最容易被忽视的地方。useLoader 会缓存加载的资源。如果你加载了 100 张图片，然后卸载了 99 个组件，只要那个 useLoader 的缓存还在，那 100 张图片依然会占用显存。
R3F 的 useLoader 有一个 clear 方法，但通常我们不手动调用它，除非我们在一个极其复杂的 SPA 应用中。
如何处理？
最稳妥的方式是，不要滥用 useLoader 来加载一次性资源。如果资源是一次性的，用普通的 useEffect + TextureLoader。
如果你必须用 useLoader 缓存，你需要确保你的组件被卸载后，能够从缓存中移除该资源。
import { useLoader } from '@react-three/fiber';
function MyModel({ url }) {
const { scene } = useLoader(Three, url);
useEffect(() => {
return () => {
// 在这里手动清理 Loader 中的缓存
// 注意：这需要你对 Loader 的内部实现有一定的了解
// 或者使用一个全局的 Loader 管理器
clearCache(url);
};
}, [url]);
return <primitive object={scene} />;
}第五章：深度协议——显存泄漏的“核弹级”反模式
有些时候，你以为你清理了，但实际上没有。我们来聊聊那些让你在深夜痛哭的代码。
1. 全局变量与静态缓存
这是最经典的反模式。
// 全局变量
let globalTextureCache = new Map();
function loadTexture(url) {
if (globalTextureCache.has(url)) {
return globalTextureCache.get(url);
}
const texture = new THREE.TextureLoader().load(url);
globalTextureCache.set(url, texture);
return texture;
}
function MyComponent() {
const texture = loadTexture('some-big-image.jpg');
// ...
}在这个例子中，globalTextureCache 永远不会清空。即使 MyComponent 卸载了，globalTextureCache 里的纹理依然存在。这会导致显存泄漏，直到浏览器崩溃。
解决方案：使用 Ref。
不要用全局变量，用 React 的 useRef 来存储资源。
function MyComponent() {
const textureRef = useRef(null);
useEffect(() => {
const texture = new THREE.TextureLoader().load('some-image.jpg');
textureRef.current = texture;
return () => {
texture.dispose();
};
}, []);
return <mesh><primitive object={textureRef.current} /></mesh>;
}2. 父子组件的“继承”陷阱
假设你有一个父组件 Scene，它加载了一个纹理。然后你有一个子组件 Cube 使用了这个纹理。
function Scene() {
const texture = new THREE.TextureLoader().load('texture.jpg');
return (
<>
<Cube texture={texture} />
<OtherCube texture={texture} />
</>
);
}
function Cube({ texture }) {
return <mesh />;
}当 Scene 卸载时，texture 对象会被回收（因为它是局部变量）。但是，Cube 组件还在尝试使用它。这会导致 texture 为 undefined，或者 WebGL 报错。
解决方案：所有权转移。
如果你想把资源传给子组件，你必须确保父组件在卸载时，清理了所有子组件正在使用的资源。或者，更简单的方法是，不要传递资源对象，而是传递资源的 URL，让子组件自己去加载（如果缓存允许的话）。
或者，使用 R3F 的 useThree 获取全局上下文，但这通常不是个好主意。
第六章：高级话题——WebGL 上下文丢失
这是资源销毁协议的终极BOSS。
如果显存泄漏得太严重，或者 GPU 资源管理混乱，浏览器会认为你的 WebGL 上下文不可用了。它会抛出一个 webglcontextlost 事件。
这时候，你的 React 应用会直接卡死，所有的 3D 场景都会变成黑屏，鼠标点击没有任何反应。
如何应对？
你需要监听这个事件。
useEffect(() => {
const canvas = document.querySelector('canvas');
const handleContextLost = (event) => {
event.preventDefault();
console.error('WebGL 上下文丢失了！');
// 这时候你需要做的是：清空所有资源，重置场景，或者刷新页面
// 在 React 中，通常的做法是重新挂载整个应用
// 但这非常痛苦，因为会丢失所有状态
};
const handleContextRestored = () => {
console.log('WebGL 上下文恢复了！');
// 重新加载资源
};
canvas.addEventListener('webglcontextlost', handleContextLost);
canvas.addEventListener('webglcontextrestored', handleContextRestored);
return () => {
canvas.removeEventListener('webglcontextlost', handleContextLost);
canvas.removeEventListener('webglcontextrestored', handleContextRestored);
};
}, []);这听起来很可怕，但只要你遵循我们的“资源销毁协议”，你就能避免走到这一步。
第七章：实战演练——编写一个“资源卫士”Hook
为了让大家更直观地理解，我写了一个自定义的 Hook，专门用来管理纹理资源。这个 Hook 会自动处理异步加载、清理函数和引用断开。
import { useEffect, useRef } from 'react';
import * as THREE from 'three';
/**
* useManagedTexture
* 一个智能的纹理管理 Hook
* @param {string} url - 纹理地址
* @param {object} options - 配置项
*/
export const useManagedTexture = (url, options = {}) => {
const {
onLoad = () => {},
onError = () => {},
dispose = true, // 默认自动销毁
} = options;
const textureRef = useRef(null);
const imageRef = useRef(null);
const loaderRef = useRef(null);
const abortControllerRef = useRef(null);
useEffect(() => {
// 如果已经有纹理了，先清理（可选，取决于你的业务逻辑）
if (textureRef.current) {
textureRef.current.dispose();
}
// 创建 AbortController 用于中断请求
abortControllerRef.current = new AbortController();
// 开始加载
loaderRef.current = new THREE.TextureLoader();
// 注意：Three.js 的 TextureLoader 不直接支持 AbortSignal
// 这里我们用一种变通方法，通过手动设置 image.src 并监听 load/error
const image = new Image();
imageRef.current = image;
// 跨域设置，防止 canvas 污染
image.crossOrigin = 'anonymous';
const handleLoad = () => {
if (abortControllerRef.current?.signal.aborted) return;
const texture = loaderRef.current.load(url, () => {
// 这里的回调是 TextureLoader 的 onload
}, undefined, (err) => {
console.error('纹理加载失败', err);
onError(err);
});
texture.colorSpace = THREE.SRGBColorSpace;
if (options.minFilter) texture.minFilter = options.minFilter;
if (options.magFilter) texture.magFilter = options.magFilter;
textureRef.current = texture;
onLoad(texture);
};
const handleError = () => {
onError(new Error('Image load failed'));
};
image.addEventListener('load', handleLoad);
image.addEventListener('error', handleError);
image.src = url;
return () => {
// 1. 中止加载
abortControllerRef.current?.abort();
// 2. 移除监听
image.removeEventListener('load', handleLoad);
image.removeEventListener('error', handleError);
// 3. 断开 JS 引用
if (imageRef.current) {
imageRef.current.src = '';
imageRef.current = null;
}
// 4. 销毁纹理
if (dispose && textureRef.current) {
textureRef.current.dispose();
textureRef.current = null;
}
};
}, [url, options]);
return textureRef.current;
};这个 Hook 做了什么？
- 自动中断：使用了
AbortController（虽然配合 Image 加载有点 hack，但有效）来确保在组件卸载时停止加载。 - 彻底断开：清理函数中不仅调用了
dispose()，还把image.src设为空，把引用设为null。 - 回调安全：通过
signal.aborted检查，防止组件卸载后回调还在执行。
第八章：调试——如何发现你的资源泄漏了？
当你觉得你的应用很卡，或者 3D 场景莫名其妙消失了，怎么知道是不是显存泄漏？
1. Chrome DevTools – Memory Tab
- 打开 Chrome DevTools。
- 切换到 Memory 标签。
- 点击 Heap snapshot。
- 点击 Take snapshot。
- 在你的应用中操作一番，比如切换页面，或者卸载/挂载组件。
- 再次点击 Take snapshot。
- 比较两个快照。
寻找 Texture 对象。如果第一个快照有 10 个 Texture，第二个快照还是 10 个，或者还在增加，那就是泄漏了。
2. Three.js Inspector
如果你在开发 R3F 应用，安装 three/examples/jsm/inspectors/Inspector.js。
window.inspect() 会打开一个面板，你可以看到 renderer.info。
点击 Textures，你会看到所有纹理的内存占用。如果这里的数据在卸载组件后没有减少，那就是你的协议出错了。
结语：做一个有“洁癖”的程序员
各位同学，React 与 GPU 资源销毁协议，本质上是一种责任。
React 负责管理逻辑的生老病死，而 WebGL 负责管理视觉的呈现。当逻辑的生命周期结束，我们必须确保视觉的残留也被清理干净。这就像打扫房间一样，你不能只把垃圾扫到床底下就不管了，那不是清洁，那是虐待。
写代码就像做人。如果你连自己创建的资源都清理不掉，谁还敢把复杂的业务交给你？
记住我们的原则：
- useEffect 的清理函数是退房协议，必须写。
- dispose() 是销毁指令，必须调。
- 断开引用是安全锁，必须做。
- 异步回调是定时炸弹，必须防。
希望大家在未来的项目中，都能写出干净、高效、不会让浏览器崩溃的代码。谢谢大家！
（台下掌声雷动……大概吧）