把第三方模型引擎接进 React 项目时，我一开始最担心的不是能不能渲染出来，而是边界怎么放。

模型引擎通常有自己的生命周期、事件、控制器、资源加载和内部状态。React 也有自己的组件状态、渲染节奏和数据流。如果直接把引擎对象暴露给页面，短期能跑，长期很难维护。

画布不是普通组件

普通前端组件的状态大多可以由 React 接管，但模型画布不一样。

引擎初始化、模型加载、视角控制、选择构件、属性读取、销毁释放，都更接近一个外部运行时。React 可以负责把它放到页面里，但不能假装它只是一个受控输入框。

所以我会把画布当成一个边界组件。外部传入配置和回调，内部管理引擎实例和生命周期。页面不需要知道每个底层 API，只需要通过组件暴露的能力完成业务动作。

模型树和属性面板是业务界面

模型引擎接入后，真正给用户用的往往不是画布本身，而是围绕画布的模型树、属性面板、进度条和操作区。

模型树要和构件选择联动，属性面板要跟当前选择同步，加载状态要让用户知道系统还在工作。这些看起来是 UI，实际上是在把底层模型能力翻译成业务界面。

我更愿意把这些东西封装成一个整体查看器，而不是让每个页面自己拼画布、树和属性面板。否则每次接入都会重复处理同一批联动问题。

控制器要克制暴露

封装 SDK 时，很容易把所有底层方法都透出去。这样看起来灵活，但会让调用方越来越依赖底层细节。

我更倾向于只暴露稳定的操作：加载模型、选择构件、读取属性、切换视角、监听事件。至于底层引擎的临时方法和复杂对象，尽量留在组件内部。

这样做会牺牲一点自由度，但换来更清楚的维护边界。后续如果引擎升级或 API 变化，影响面也更小。

封装不是遮住复杂度

好的封装不是把复杂度藏起来假装没有，而是让复杂度留在合适的位置。

模型引擎本身仍然复杂，加载失败、资源大小、浏览器性能、销毁泄漏、事件顺序都需要处理。React 组件只是把这些问题集中到一个地方，让业务页面不要重复承担。

这次经验让我对“接 SDK”这件事更谨慎。真正的集成不是能调通 API，而是把外部运行时变成团队能稳定使用的组件。