用途：当 3D 运行时需要嵌入 React 应用时使用本技能，它是插件中默认的 React 原生 3D 路径；若应用外壳、设置、商店页、编辑器或周边产品已使用 React，应优先于原生 Three.js 采用本方案。项目非 React、想用更纯粹的命令式运行时，或问题属于资源打包而非运行时组合时，不建议使用。
推荐技术栈：@react-three/fiber、three、@react-three/drei、@react-three/rapier、@react-three/postprocessing，以及在无障碍交互敏感时使用 @react-three/a11y；HUD 等使用普通 React 树中的 DOM 覆盖层。
主要能力与适用场景：3D 配置器与工具型浏览器产品；内嵌游戏或场景界面的 React 应用；已有 React 应用中的 3D 菜单、编辑器或世界地图；依赖共享应用状态与非 canvas 外壳的 3D 游戏 UI。
核心规则：把模拟状态放在渲染组件之外，React 组件只描述场景组合，不充当玩法规则的唯一来源；谨慎区分 React 状态与场景状态，高频模拟不应引发整应用不必要的 React 重渲染；有选择地使用 pmndrs 辅助库（drei 负责控制器、加载器、环境与常用场景原语，rapier 负责物理，postprocessing 负责可选特效）；HUD、设置与菜单默认保留在 DOM 中。
架构建议：用专用场景根组件持有 Canvas；将相机装置与控制组件同玩法系统隔离；保持加载器与资源包装可预期；通过显式状态边界协调 DOM 覆盖层与 3D 场景；需要强命令式控制的系统单独隔离。初始脚手架外观克制，先提供一个紧凑目标或状态面与临时提示。
反模式：把 React 组件当作玩法状态存储；通过宽泛应用状态推送大量逐帧变更；仅因存在 React 就使用 R3F；默认在 3D 场景内构建 HUD 或背包 UI；初始脚手架让大型卡片占满视口各边。