在一个支持动态替换模型的 3D 场景里，资源换掉之后，依赖这份资源的交互不一定会自动跟着更新。
我之前在一个综合原型里遇到过这样的情况：切换到新的模型文件以后，直线测量、笔记和立方体工具都无法再点击模型，唯独体积测量仍然正常。
一开始很容易把它理解成几个功能各自出了问题。但继续往下排查后发现，真正失效的是更底层的事件绑定：新模型虽然已经显示出来，指针事件却没有重新正确挂到新的模型节点上。
这个问题的关键在于：视觉内容已经变化，不代表框架认为"组件身份"也发生了变化。 如果下游能力依赖旧对象引用建立，而框架复用了原来的外壳，那么事件、订阅或其他绑定关系就可能留在陈旧状态。
根因诊断和具体修复主要来自 Claude Code，我负责在替换不同模型后逐项验证所有交互是否恢复。
模型地址变化时，加载组件没有一个会随资源变化的唯一标识。
因此框架没有完整卸载旧组件再创建新组件，而是复用了同一个外层实例，只把内部内容替换成新的模型。
对纯视觉结果来说，这种复用没有问题：用户确实已经看到了新模型。
但事件系统依赖的是对象引用和节点注册关系。外壳引用没有变化时，负责事件命中和派发的下游逻辑并不会天然知道内部资源已经彻底换了一份，于是新模型可能继承不到正确的事件注册。
结果就是：模型看起来加载成功，但最底层的 pointer down / pointer up 都没有触发。
这类问题很容易被误判，因为页面没有报错，模型也正常显示。真正坏掉的是"围绕这份资源建立起来的关系"，而不是资源本身。
最终的处理方式，是给模型加载组件加一个和模型地址绑定的唯一标识。
当模型地址变化时，这个标识也变化，框架就不再把它视为"同一个组件更新内容"，而是执行完整的卸载和重新挂载。
这样新的容器、模型节点和引用都会重新建立，依赖这些引用的事件注册也能重新初始化。
这里真正需要保证的不是"每次都强制重建"，而是：当资源变化意味着对象身份已经变化时，框架层也必须显式知道这是一个新对象。
如果只是内容细节更新，复用当然有价值；但如果下游系统把对象引用本身当成能力绑定的基础，身份变化就不能被隐藏在内部更新里。
模型加载组件需要一个随资源变化的稳定唯一标识，例如和模型 URL 绑定的 key。
资源变化后触发完整 remount，使事件注册、引用和相关副作用重新建立。
排查时先确认最底层 pointer 事件是否触发，再继续检查拾取和各具体功能逻辑。
这次最容易误导排查方向的现象，是体积测量仍然可以正常工作。
直线测量、笔记和立方体工具都需要用户真正点击模型，因此依赖模型节点上的指针事件。
体积测量走的是另一条路径：它主要基于场景整体边界框计算参考面，并不依赖用户在模型表面完成一次真实命中。
所以它没有"躲过"同一个 bug，而是根本没有经过已经失效的事件链路。
这件事提醒我，一个功能仍然正常，并不能证明共享底层机制大体正常。 更值得问的是：它是不是压根没有依赖同一层。
这类问题如果直接从具体功能开始查，很容易花很多时间在错误层级。
更有效的顺序是从最底层往上确认：
如果第一步就没有发生，继续检查测量算法、笔记逻辑或立方体创建流程都没有意义。
尤其当多个功能同时失效时，应该优先寻找它们共同依赖的那一层，而不是默认它们刚好各自坏了。
这次问题也是在"支持切换模型"之后才出现的。
新增资源替换能力时，很容易只验证：
但真正需要回归的还包括所有依赖这份资源的交互：选择、测量、标注、对象创建以及其他命中逻辑。
因为资源替换不只是内容变化，它也可能改变引用、生命周期、事件注册和缓存关系。
因此，对动态资源功能来说，测试重点不能停在"新内容出现了"，还要确认"围绕旧内容建立的能力是否已经正确迁移到新内容上"。
这次具体的事件失效原因和 remount 修复主要由 Claude Code 协助定位，我负责确认问题是否真的是共享层级导致，以及替换模型后所有依赖功能是否都恢复正常。
对我来说，这次更值得保留的不是"记得给组件加 key"，而是一个更通用的判断：只要系统里有能力是围绕某个对象引用建立的，就要警惕框架复用对象身份时，内容已经变化但下游关系没有同步更新。
这个问题不限于 3D 模型，也适用于事件、订阅、观察器、缓存和任何基于对象身份建立的副作用。