我已经在Unreal Engine中独立开发了很长时间，100%使用蓝图。某一天我注意到，相同的模式一直让我浪费时间：打印字符串调试是可有可无的。你写了它，它帮助你五分钟，之后它就消失了——六个月后在同一个项目中，你遇到一个你以前解决过的bug，却完全忘记了如何解决。这一观察使我走向了设计问题的深渊，我认为这些问题不仅适用于我的工具，还适用于其他人：

暂时性vs持久性调试。

大多数调试日志都是暂时的。然而，在长期项目（例如，我的客户开发的逃脱游戏系统和游戏框架）中，bug发生的上下文（为什么发生，如何解决）往往比日志本身更有价值。最终，我建造了一个系统，允许你直接将自己的注释（原因和解决方案）附加到特定错误/警告触发器上，这样“知识”就可以在项目整个生命周期中持续存在，而不是滚动到屏幕外。

性能vs可见性权衡。

如果不谨慎（Tick-basedpolling，早期退出），运行时监视是昂贵的。为了避免浪费周期，我选择了delta-update逻辑——UI仅在被跟踪值实际发生变化时刷新——以避免在没有移动的值上浪费周期。同时，我还必须考虑安全性：任何调试相关的内容都必须在打包构建中完全编译出来，而不是仅仅隐藏。

严重性，而不是数量。

当你跟踪的变量/事件超过一手套时，未分级的日志就变成了噪音。我将警报分为严重性等级，以确保关键信息不会被低优先级通知淹没。这个想法我转化为一个小插件（100%蓝图，无C++），它现在已经在Fab上线了。这是我在Fab上发布的第一个产品——不打算在这里链接它，因为这不是这个帖子的重点，但我很乐意深入探讨上述设计决策中的任何一个，或者如果有人在自己的项目中解决了这个问题，我很想听听。