Unreal Engine 游戏埋点：一套不阻塞游戏线程的遥测架构

一次玩法埋点调用只应构造经过校验的事件，然后立即返回。它不应等待 DNS、TLS、HTTP 响应或磁盘刷新。排队与传输属于独立子系统，并拥有自己的节奏、状态和失败策略。

应用会话状态应由单一的 GameInstance 级对象管理。游戏循环开始时生成单局标识，并用受约束的结果显式关闭。这样可以避免分散 Actor 生成不兼容 ID，也能避免地图切换时丢失共享上下文。

内存与磁盘队列都必须有明确的条数和字节上限。达到上限时执行有文档的策略——通常优先丢弃最旧的低优先级事件，并尽量保留生命周期结束事件。无限增长的“可靠队列”只是一次延迟发生的崩溃。

按事件数、编码后体积和最大等待时间共同控制批次。对临时失败使用带抖动的指数退避；对永久性的 schema 或认证错误应直接拒绝，不能无限重试。磁盘只持久化重启后确有必要且安全重放的数据。

购买事件应在服务器或权威游戏状态确认后发送，而不是点击按钮时发送。伤害应记录减免后的实际伤害；匹配成功应在队伍真正进入会话后记录。这样指标对应的是结果，而不是意图。

在条件允许时，把事件名与分类字段做成受约束的 API。客户端校验数值范围、字符串长度和允许字段，接收端再次校验。事件协议应独立于游戏版本进行版本化，才能观察兼容性。

使用项目范围内的匿名标识。除非存在有文档、合法且受妥善保护的明确需求，不要采集原始 Steam 或平台账号 ID。显示名、聊天内容、任意异常文本和文件路径都不应成为分析维度。

运行时关闭遥测后，应立即停止新数据采集，并明确如何处理已排队事件。数据保留、删除和访问边界都应使用玩家与开发团队能够理解的语言写入文档。

测试正常退出、进程终止、断网、长时间离线、重复重试、时钟偏差、异常载荷、密钥过期和协议版本不匹配。在开发诊断视图中展示队列深度、接受/拒绝数量、最后成功刷新时间和协议版本。

最后执行一条已知的脚本化试玩流程，从客户端日志、接收响应、数据行到仪表盘指标逐层核对预期事件。图表能够正常渲染，并不能证明它的分母正确。