当我使用VConsole.destory销毁实例后会在控制台出现报错

[nice-wwming]

vConsole Version:3.15.1
报错详细内容：
Uncaught TypeError: Cannot read properties of undefined (reading 'update')
at u2 (vconsole.min.js:10:91405)
at e2._flushLogs (vconsole.min.js:10:91641)
at vconsole.min.js:10:91147

[shunia]

果然是个老问题：#587
真巧咱俩最近都遇到了，我翻了一下源代码，应该是因为log.model里面的限流逻辑window.requestAnimationFrame的回调方法_flushLogs里面的代码导致的。

我的log是一个interval性质的，调用destroy之后，log.model的unbind方法没有正确的屏蔽掉限流逻辑，但是又把Store里的东西删了，导致限流回调触发后可能会去获取Store里面的内容，但是获取的代码没做空保护，从而触发报错了。

这个改动的方法很多，比如在unbind的时候清空logQueue，比如增加一个flag来阻止限流回调的运行同时阻止addLog的执行，比如在限流回调中获取store的时候加一个空保护。

做一个空保护是最简单的，但是从代码设计的角度来说也许不是最优的。

[shunia]

果然是个老问题：#587 真巧咱俩最近都遇到了，我翻了一下源代码，应该是因为log.model里面的限流逻辑window.requestAnimationFrame的回调方法_flushLogs里面的代码导致的。

我的log是一个interval性质的，调用destroy之后，log.model的unbind方法没有正确的屏蔽掉限流逻辑，但是又把Store里的东西删了，导致限流回调触发后可能会去获取Store里面的内容，但是获取的代码没做空保护，从而触发报错了。

这个改动的方法很多，比如在unbind的时候清空logQueue，比如增加一个flag来阻止限流回调的运行同时阻止addLog的执行，比如在限流回调中获取store的时候加一个空保护。

做一个空保护是最简单的，但是从代码设计的角度来说也许不是最优的。

更正一下触发的原因，并不是因为interval性质的log导致的，而是在destroy之前打一条log就可以必现这个报错。

[suzhenghui-sky]

果然是个老问题：#587 真巧咱俩最近都遇到了，我翻了一下源代码，应该是因为log.model里面的限流逻辑window.requestAnimationFrame的回调方法_flushLogs里面的代码导致的。
我的log是一个interval性质的，调用destroy之后，log.model的unbind方法没有正确的屏蔽掉限流逻辑，但是又把Store里的东西删了，导致限流回调触发后可能会去获取Store里面的内容，但是获取的代码没做空保护，从而触发报错了。
这个改动的方法很多，比如在unbind的时候清空logQueue，比如增加一个flag来阻止限流回调的运行同时阻止addLog的执行，比如在限流回调中获取store的时候加一个空保护。
做一个空保护是最简单的，但是从代码设计的角度来说也许不是最优的。

更正一下触发的原因，并不是因为interval性质的log导致的，而是在destroy之前打一条log就可以必现这个报错。

是的，我把关闭之前的log关了就不报错了。感谢