Cesium/Resium应用未递归却触发React更新深度超限警告是否合理？

先说结论：这大概率是大规模组件渲染/更新引发的连锁效应触发了React的安全限制，但也不能完全排除还存在隐性递归更新的可能。

具体拆解： #

1. 数量阈值特征指向性能瓶颈

   • 只有当点数量突破7000-8000才会触发警告，说明问题和组件规模直接挂钩。React的Maximum update depth exceeded本来是防止无限递归的，但当几千个可点击、带动画的点组件（每个都是独立React节点）同时触发更新时，React内部处理副作用的recursivelyTraverseMutationEffects递归逻辑会被放大，堆叠的更新操作超出了React的安全深度限制，从而触发警告。

2. 仍需排查隐性递归场景

   • 虽然你已经修复了那个会更新自身触发条件的useEffect，但还有其他容易忽略的递归更新情况：
     • 点的点击/动画回调里，是不是直接或间接修改了父组件的状态？父组件状态更新又会重新渲染所有点，形成“父更新子→子触发父更新”的循环？
     • 有没有用Resium的封装组件，内部存在未处理好的状态更新逻辑，当实例化几千个时，互相触发连锁更新？
     • 检查useCallback/useMemo的依赖项是不是没加对，导致每次渲染都生成新的回调或计算值，逼着子组件反复更新，形成更新风暴？

3. 针对性优化方向

   • 放弃单个点的React组件封装：别给每个点都做React组件，改用Cesium原生的Primitive或Entity批量渲染，只用React管理整体的点数据，不用管单个点的状态。
   • 批量处理状态更新：用React的unstable_batchedUpdates把批量状态更新包起来，避免多次小更新触发多次渲染。
   • 视口裁剪/虚拟化：只渲染当前视口内的点，超出的暂时隐藏或卸载，减少同时在React渲染树里的组件数量。
   • 追踪更新触发源：在所有触发状态更新的地方加日志，看清楚更新是从哪来的，有没有形成A更B、B更A的循环链。

内容的提问来源于stack exchange，提问作者ResiumRegent