React Three Fiber：在 WebGL 的泥泞中，谈一场优雅的“声明式”恋爱
欢迎来到 WebGL 的深渊。在这里，没有 React 的优雅，没有组件的生命周期，只有冰冷的 gl.drawArrays 和随时准备吞噬你 GPU 内存（VRAM）的幽灵。
作为在这个领域摸爬滚打多年的“资深老司机”，今天我要带你坐上 React Three Fiber（R3F）这辆战车。我们的目标很简单：用 React 的声明式思维去驯服 WebGL 这头野兽，并且——这是最重要的——确保我们在分手（组件卸载）时，不会留下任何“垃圾”（内存泄漏）。
准备好了吗？让我们开始这场技术探险。
第一章：React 与 WebGL 的“相爱相杀”
首先，我们要搞清楚为什么我们需要 React Three Fiber。
传统的 WebGL 开发，基本上就是一场命令式的噩梦。你想画个圆？行，先生，你得先 createShader，再 createProgram，接着 gl.attachShader，然后 gl.linkProgram。如果你想换颜色？gl.clearColor。想画个三角形？gl.drawArrays。
这就像你是个木匠，但木匠不是直接递给你木头和锤子，而是递给你一堆生锈的铁片，让你自己打磨、自己组装，最后还得自己把木屑扫干净。如果你忘了扫，下次你想再打磨的时候，你会发现那堆木屑已经把你埋了。
React Three Fiber（R3F） 是干嘛的呢？它是个翻译官，是个保姆。它把 WebGL 的命令式 API 封装成了 React 的声明式组件。
在 R3F 里，画个三角形不再是痛苦的命令流，而是：
import { Canvas, Mesh } from '@react-three/fiber'
function Triangle() {
return (
<mesh>
<boxGeometry args={[1, 1, 1]} />
<meshStandardMaterial color="hotpink" />
</mesh>
)
}
function App() {
return (
<Canvas>
<Triangle />
</Canvas>
)
}看，这就很 React。没有 gl 上下文，没有 dispose 手动调用，没有地狱般的回调嵌套。React 会自动处理场景图的构建。当你删除 <Triangle /> 组件时，R3F 会自动帮你把 WebGL 里的东西清理掉。
但是！ 别高兴得太早。React 的自动清理虽然强大，但它不是魔法。如果你在组件里搞了一些“私生子”（比如直接引用了 WebGL 的对象而没有告诉 React），React 就会以为它们是无关紧要的垃圾，从而让它们留在 GPU 内存里慢慢腐烂。这就是我们要解决的——资源管理。
第二章：场景图的“父子”关系与生命周期
在 React 中，组件有 useEffect 和 useLayoutEffect。在 R3F 中，场景图也有类似的生命周期，不过它是基于帧的。
当你把 <mesh> 放在 <group> 里，或者放在 <Canvas> 里，你就建立了一个父子关系。这个关系在 React 里是通过 Props 传递的，但在 WebGL 里，它是通过 scene.attach(child) 和 scene.detach(child) 实现的。
1. useFrame：React 的 requestAnimationFrame
React 组件默认是在状态改变时渲染。但在 3D 里，我们需要每一帧都重新计算。R3F 提供了 useFrame，这基本上就是 React 版的 requestAnimationFrame。
import { useFrame } from '@react-three/fiber'
function RotatingCube() {
const meshRef = useRef()
useFrame((state, delta) => {
// 这里的 state 是 useThree 的 store
// 这里的 delta 是两帧之间的时间差
if (meshRef.current) {
meshRef.current.rotation.x += delta
meshRef.current.rotation.y += delta
}
})
return <mesh ref={meshRef}><boxGeometry /><meshStandardMaterial /></mesh>
}注意： useFrame 会在组件卸载后继续运行吗？不会。R3F 的内部机制会在组件卸载时自动移除该组件的回调，这很安全。但如果你在 useFrame 里面引用了外部的变量，并且这些变量在组件卸载后改变了，可能会导致“闭包陷阱”或者访问已销毁的 DOM/Canvas 对象。
2. useEffect：真正的“分手”时刻
这是我们今天要讲的重点。当组件卸载时，React 会执行清理函数。在 R3F 中，这意味着我们要在这个时候清理 WebGL 资源。
场景： 你有个组件叫 ParticleSystem，它创建了一个包含 10000 个粒子的 BufferGeometry。
function ParticleSystem() {
const [particles, setParticles] = useState(null)
useEffect(() => {
// 假设我们在这里用 Three.js 原生 API 创建了 10000 个点的数据
const geometry = new THREE.BufferGeometry()
const positions = new Float32Array(10000 * 3)
// ... 填充数据 ...
geometry.setAttribute('position', new THREE.BufferAttribute(positions, 3))
setParticles(geometry)
// 返回清理函数
return () => {
// 这里！是关键！
// 必须手动调用 dispose，否则 WebGL 不会释放内存
geometry.dispose()
// 如果有材质，也要 dispose
}
}, [])
return <points geometry={particles} />
}如果你忘了 geometry.dispose()，React 只会认为你传给 <points /> 的 geometry prop 变了（null -> object -> null），从而卸载组件。但是那个 geometry 对象在 WebGL 那边依然存在，占着内存不放。
第三章：资源管理的“垃圾回收”大作战
在 React Three Fiber 中，资源管理主要分为两类：显式资源（如 Geometry, Material, Texture）和上下文资源（如 Renderer, Camera, Scene）。
1. useLoader：React 的“自动保姆”
R3F 内置了 useLoader 钩子，这是处理资源加载最安全的方式。它不仅能加载模型，还能自动处理资源销毁。
import { useLoader } from '@react-three/fiber'
import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader'
function ModelViewer() {
const gltf = useLoader(GLTFLoader, '/models/robot.glb')
// useLoader 返回的数据结构里包含了 scene
// R3F 会自动把 scene 的子元素挂载到 Canvas 里
return <primitive object={gltf.scene} />
}它的魔法在于： 当你的 ModelViewer 组件卸载时，R3F 会自动遍历 gltf.scene 的所有子对象，并调用它们的 .dispose() 方法。这省去了你写一大堆 scene.traverse(child => child.dispose()) 的代码。
2. useThree：访问“上帝视角”
有时候，你需要在组件外部或者非渲染循环中操作 Three.js 的核心对象。这时候要用到 useThree。
import { useThree } from '@react-three/fiber'
function DebugInfo() {
const { camera, gl, size } = useThree()
// 访问渲染器
console.log(gl.info)
return <div>Viewport: {size.width}x{size.height}</div>
}警告： useThree 返回的 gl 是同一个渲染器实例。如果你在组件卸载时试图调用 gl.dispose()，这通常是个坏主意。为什么？因为 gl 是全局共享的。如果你销毁了它，那么你的整个应用（比如其他还没卸载的 Mesh）也会跟着完蛋。
正确姿势： 只在需要时访问 gl 进行读取（如 gl.info），不要去修改它，更不要在 useEffect 的清理函数里销毁它。
第四章：实战演练——如何正确地“分手”
光说不练假把式。让我们看几个具体的案例，看看如何在代码中优雅地处理资源。
案例一：动态加载纹理与清理
假设你有一个画廊组件，每次渲染时加载一张新图片。
import { useLoader, useFrame } from '@react-three/fiber'
import { TextureLoader } from 'three'
function GalleryItem({ url }) {
const texture = useLoader(TextureLoader, url)
// 在渲染循环中，我们可以根据时间改变纹理的偏移量，实现“卷轴”效果
useFrame((state, delta) => {
texture.offset.x -= delta * 0.5
})
// 关键点：React 知道 url 变了，所以 texture prop 变了
// R3F 会自动卸载旧的 mesh 和 texture
return (
<mesh>
<planeGeometry args={[2, 2]} />
<meshBasicMaterial map={texture} />
</mesh>
)
}分析： 这里非常安全。TextureLoader 返回的纹理是引用。当 GalleryItem 组件被卸载（比如父组件传了新的 url），React 会卸载 <mesh>，R3F 会自动销毁 <meshBasicMaterial>，进而销毁 texture。内存自动回收。
案例二：手动创建的几何体与 useEffect 清理
如果你需要手动创建一个复杂的几何体（比如基于数学公式生成的），你必须手动管理它的生命周期。
function DynamicMesh() {
const geometryRef = useRef()
const materialRef = useRef()
useEffect(() => {
// 创建几何体
const geometry = new THREE.IcosahedronGeometry(1, 1)
geometryRef.current = geometry
// 创建材质
const material = new THREE.MeshNormalMaterial()
materialRef.current = material
// 将几何体和材质赋值给 ref，以便在 JSX 中使用
return () => {
// 清理函数：这是 React 的契约
// 当组件被移除时，必须销毁这些资源
if (geometryRef.current) geometryRef.current.dispose()
if (materialRef.current) materialRef.current.dispose()
}
}, [])
return (
<mesh geometry={geometryRef.current} material={materialRef.current}>
<meshStandardMaterial color="white" />
</mesh>
)
}注意： 这里有个陷阱。我们在 useEffect 里创建了 geometry 和 material，但在 JSX 里我们又传了一个 <meshStandardMaterial color="white" />。这会导致什么？
React 会认为你传了两个材质。R3F 会优先使用 ref 里的 material。但是，那个 <meshStandardMaterial color="white" /> 也会被挂载。当你卸载组件时，R3F 会尝试 dispose 两个材质。这虽然通常不会报错，但属于“多此一举”。
优化后的写法：
function DynamicMesh() {
const groupRef = useRef()
useEffect(() => {
const group = new THREE.Group()
const geometry = new THREE.IcosahedronGeometry(1, 1)
const material = new THREE.MeshNormalMaterial()
const mesh = new THREE.Mesh(geometry, material)
group.add(mesh)
groupRef.current = group
return () => {
// 清理：从场景图中移除，并销毁资源
if (groupRef.current) {
groupRef.current.traverse((child) => {
if (child.isMesh) {
child.geometry.dispose()
child.material.dispose()
}
})
// 注意：这里不需要 group.dispose()，因为 Group 不是 WebGL 资源
}
}
}, [])
return <primitive object={groupRef.current} />
}案例三：EffectComposer 的清理
当你使用后处理效果（如 Bloom, DepthOfField）时，你需要使用 EffectComposer。这些 Pass 对象也是需要销毁的。
import { EffectComposer, Bloom } from '@react-three/postprocessing'
function PostProcessingScene() {
return (
<Canvas>
<ambientLight />
<mesh><sphereGeometry /><meshStandardMaterial /></mesh>
<EffectComposer>
<Bloom luminanceThreshold={0} luminanceSmoothing={0.9} height={300} />
</EffectComposer>
</Canvas>
)
}分析： EffectComposer 和 Bloom 组件负责管理这些复杂的 Pass 对象。当 <PostProcessingScene> 卸载时，R3F 会自动销毁 EffectComposer 及其所有子 Pass。这又是一次“自动保姆”的胜利。
第五章：深入底层——onBeforeCompile 与自定义着色器
当你需要完全控制渲染管线时，你会用到 onBeforeCompile。这是最危险的地方。因为你在修改着色器，而着色器是直接运行在 GPU 上的。
function CustomShaderMesh() {
const meshRef = useRef()
useFrame((state) => {
// 我们可以在 JS 层面修改 Uniforms
if (meshRef.current) {
meshRef.current.material.uniforms.uTime.value = state.clock.elapsedTime
}
})
return (
<mesh ref={meshRef}>
<boxGeometry />
<shaderMaterial
uniforms={{
uTime: { value: 0 },
}}
vertexShader={`varying vec2 vUv; void main() { vUv = uv; gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.0); }`}
fragmentShader={`uniform float uTime; varying vec2 vUv; void main() { gl_FragColor = vec4(vUv.x + uTime, 0.0, 1.0, 1.0); }`}
/>
</mesh>
)
}资源管理要点： 自定义 ShaderMaterial 里的 Uniforms 对象，以及 Geometry，Material 本身，都需要遵循标准的清理规则。如果这个组件卸载了，记得 dispose 材质。
第六章：那些年我们踩过的内存泄漏的坑
即使有 React 的自动清理，依然有很多坑。
坑 1：在 useFrame 中引用外部对象
这是最常见的性能杀手。
function BadComponent() {
const myTexture = useLoader(TextureLoader, '/img.jpg')
useFrame(() => {
// 坏！如果 myTexture 在组件卸载后变了，这里会报错或者崩溃
// 而且这个闭包会一直持有 myTexture 的引用，阻止垃圾回收
console.log(myTexture)
})
return <mesh><planeGeometry /><meshBasicMaterial map={myTexture} /></mesh>
}修复： 使用 useThree 的 store 或者将数据作为 ref 传递进去，或者确保闭包逻辑是稳定的。
坑 2：直接操作 DOM
不要在 R3F 组件里直接操作 <canvas> 元素。
function BadDOMInteraction() {
const canvasRef = useRef()
useEffect(() => {
const canvas = canvasRef.current
// 别这么做！R3F 已经接管了 canvas
// 你这样做会干扰 R3F 的渲染循环
canvas.addEventListener('mousedown', ...)
}, [])
return <canvas ref={canvasRef} />
}坑 3：滥用 useMemo 和 useCallback 导致性能瓶颈
在 3D 场景中，useMemo 用来缓存 Geometry 和 Material 是没问题的。但是，不要滥用。
function OverOptimized() {
const geometry = useMemo(() => new THREE.BoxGeometry(1,1,1), [])
return <mesh geometry={geometry}>...</mesh>
}分析： 这其实没问题，因为 Geometry 是昂贵的。但是，如果你把整个场景树都放在 useMemo 里，那就搞笑了。React 会认为这是一个全新的树，从而触发不必要的卸载和挂载，导致巨大的性能损耗。
第七章：高级技巧——drei 库的神助攻
在 R3F 生态中，drei 是我们的得力助手。它封装了很多复杂的资源管理逻辑。
比如 Html 组件，它会在组件卸载时自动清理 DOM 元素。比如 Environment 组件，它会自动加载 HDR 环境，并在卸载时清理。
再比如 useTexture，它也是基于 useLoader 的封装，更加方便。
使用 drei 的好处： 它帮你做了很多脏活累活。当你不再需要某个组件时，你不需要去写 dispose 逻辑，因为 drei 已经帮你处理好了。
第八章：总结——如何成为一名 R3F 专家
要掌握 React Three Fiber 的资源管理，你需要记住以下几点心法：
- 相信 React 的生命周期： 组件卸载 -> 执行
useEffect清理函数。这是你清理 WebGL 资源的唯一合法时机。 - 显式清理显式资源： Geometry, Material, Texture, ShaderMaterial, Framebuffer。这些对象不是 React 组件，它们不会自动消失。你必须手动调用
.dispose()。 - 信任
useLoader： 除非你有极其特殊的理由，否则尽量使用useLoader来加载模型和纹理，让 R3F 帮你自动清理。 - 警惕
useThree：useThree返回的gl是全局的，不要销毁它。 - 闭包陷阱： 在
useFrame中引用外部变量时，要小心它们的生命周期，避免引用已销毁的对象。
最后，记住这句话：
“在 WebGL 的世界里，资源就像青春，一旦挥霍，就再也回不来了。而在 React 的世界里，我们要学会在分手时体面地清理现场。”
现在，拿起你的代码，去构建那些宏伟的 3D 应用吧！但别忘了，当你完成了你的杰作，当你准备展示给世界看的时候，确保你的程序跑得轻盈，就像你刚洗完澡一样干净。
祝你好运，开发者！