React 状态石墨灰 · 标准 · 无靠垫3D 画面里—
网页 3D · 底座与选型
React Three FiberReact Three Fiber
R3F 让你用 React 组件写 three.js 场景：状态一变画面就变，卸载时自动清理；代价是多一层依赖和 React 心智，而且仍然只能在浏览器端渲染。
同一个 3D 椅子配置器，两种写法跑两项验收
本页没有安装 React Three Fiber，下面用 three.js 真实渲染，模拟两种写法的结果差异。先在 R3F 写法下改颜色、点 5 次「离开页面再回来」；再切到「直接 three.js」（默认模拟 AI 忘了写同步和清理）重跑，看椅子和显存读数有什么不同。
第 0 步 · 在 Next 里'use client'dynamic(() => import('./Chair3D'), { ssr: false })3D 只能在浏览器里画：服务器上没有显卡，也没有 canvas。
<mesh> <boxGeometry /> <meshStandardMaterial color={color} /></mesh>// 状态变 → 自动更新；组件卸载 → 自动 dispose
renderer.info.memory—等待画面
| 改配置后，画面跟着状态变 | 未测 |
|---|---|
| 进出 5 次，显存资源不涨 | 0/5 |
正在按需加载 3D 引擎……
知识点：R3F 是 three.js 的 React 写法
刚才两种写法画出来的是同一把椅子，差别全在「谁负责同步和清理」。
- R3F 用 React 组件描述 three.js 场景：<mesh>、<meshStandardMaterial color={color} /> 这类标签直接对应 three.js 对象，React 状态一变，画面就跟着变。
- 组件卸载时，R3F 会自动释放它创建的几何体、材质和贴图；直接写 three.js 时这一步要 AI 手写，忘了就会越用越占显存。
- R3F 仍是客户端渲染：服务器发来的 HTML 里只有空容器。Next 项目里 3D 组件要标 'use client'，常用 next/dynamic 加 ssr: false 引入。
- 取舍：React / Next 项目、3D 要和表单、购物车等状态联动 → R3F；只是一个独立小演示，或项目不是 React → 直接 three.js 更轻。drei 是 R3F 最常用的工具集（控制器、加载器、文字等现成组件）。
什么时候用、怎么验收
看到 @react-three/fiber 出现在依赖里时，用下面几条检查 AI 的活。
- 信号：项目是 React / Next，3D 要响应按钮、表单、筛选等页面状态，或者有多个 3D 区块要复用。
- 不适用：页面只有一个装饰性 3D 动画、项目不是 React，或者团队不熟 React——多一层依赖不划算，直接 three.js 即可。
- 验收一：改页面上的选项（颜色、尺寸），3D 画面立刻跟着变，没有「选了红色、模型还是灰」的情况。
- 验收二：在 3D 页面和其他页面之间来回切换 5 次，让 AI 打印 renderer.info.memory，几何体和贴图数不增长。
- 验收三：查看网页源代码（服务器 HTML），3D 区域是占位而不是报错；构建（npm run build）不出现 window is not defined。
正反例：同一个 Next 椅子配置器
需求只差一句话，用户切几次页面后体验完全不同。
AI 直接用 three.js 在 useEffect 里建场景，只在开始时读了一次颜色，也没写清理：用户换了颜色模型不变，来回切几次页面后越来越卡。
状态一变画面就变，卸载由 R3F 自动清理；验收标准写进了需求，AI 交付时附上 renderer.info 读数。
快速自测
你的项目是一个纯 HTML 的活动页（没有 React），只要放一个会自转的 3D 奖杯。AI 提议引入 React、React DOM 和 @react-three/fiber 来做。怎么判断？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。