调试：从浏览器走到微信真机
调试先收集证据：哪个版本、哪个环境、怎样操作、预期和实际是什么。截图能说明画面，日志能说明事件，两者一起才容易定位。
按层排查
日志记录足够定位的信息
推荐：构建版本、场景、phase、roundId、请求 ID、错误类别。不要记录完整 token、登录 code、AppSecret 或完整用户隐私数据。
把高频逐帧日志临时关掉，否则你很难从几千行位置输出中找到一次错误结算。收到错误后保留第一条有意义的堆栈，后续报错可能只是连锁结果。
前后台测试不能省
一局进行到一半切到其他应用，等待十秒再回来；锁屏再解锁；广告打开后返回；网络请求期间切后台。每次观察计时、音频、输入和回调。
对于点击收集案例，正式接微信时需要做一个明确决定：
- 前台游玩计时：隐藏时暂停，恢复时从原余量继续，处理恢复首帧时间。
- 现实时间计时：保存截止时间，恢复时按可靠时间重新计算；关键活动依赖服务端时间。
两者都是合理产品规则，但不能混用。不要为了“看起来没跳秒”随意截断 dt，却不说明它改变了时间语义。
给 AI 一份有效问题报告
Creator 3.8.8，微信真机，iOS/Android版本与基础库见附件记录。
步骤：开局→点击三次→切后台10秒→回来→重新开始。
预期：按前台计时规则恢复，重开只启动一个倒计时。
实际：重开后一秒减两秒。
提供：节点树、ClickCollector.ts、首次错误日志、构建提交号。
请先找重复监听/定时任务的来源，再给最小修复。
验收修复时重跑原步骤，并补重复启停、退出场景和快速点击。仅“这次没出现”不足以说明生命周期问题已解决。