最近在跑一个合成消除类小游戏的回归测试时日志里反复出现“检测到双果冻双红宝石”。第一次看到这条消息容易把它当成普通掉落公告同时出现了两个果冻和两个红宝石说明资源刷得不错。但如果你负责开发或者测试环境这条消息更像一个事件检测日志需要从场景数据、匹配规则和事件去重三个角度去看。它本身不代表玩法出错但出现时机不对、出现次数异常往往能顺藤摸瓜找到隐藏问题。下面按我实际排查的顺序把这类日志从“看到”到“定位”再到“回归验证”完整拆一遍。合成消除、方块匹配、道具掉落类项目都可以参考。1. 先搞清楚“检测到双果冻双红宝石”是一类什么日志1.1 业务事件日志和玩家公告不要混为一谈玩家公告一般会写成“恭喜获得果冻2、红宝石2”面向正常用户文本自然不会出现“检测到”这种系统词。面向开发或测试的事件日志则不同它要保留事件名、触发角色、目标对象、帧号、时间戳等上下文。拿我这边项目来说“检测到双果冻双红宝石”不是由 UI 文案层输出的而是由事件检测模块在某个检测周期内输出的一条业务日志。它表达的事情是系统同时识别出两个果冻和两个红宝石满足了某个组合条件。这个区分很重要。如果你拿“检测到”去和玩家公告做对比会越看越奇怪如果按事件日志来看就会顺理成章。日志系统里最好把“业务公告”“事件日志”“异常日志”分开放用不同前缀或者不同 topic。否则后面查问题的时候很容易把正常事件当成错误或者把配置错误当成正常公告。1.2 为什么是“双果冻”和“双红宝石”两个维度“双果冻双红宝石”不是一个布尔值而是一个计数结果。它至少包含两个维度目标类型和数量。果冻是一种类型红宝石是另一种类型两种都是 2 个组合起来才形成这条消息。在合成消除类游戏里一次检测可能同时处理多个目标类型。目标类型一多组合条件也变多比如“三消”“双消除”“同色连击”“宝石累积”等。为了降低误报率检测模块通常会先按类型分组再对每组数量做阈值判断最后才合成一条事件消息。单看这条日志还不能直接判断是好是坏需要进一步确认当前场景是否真的有对应数量的目标对象这些目标对象是否都处于可以被匹配的状态这条事件在同一帧内是否只上报了一次上报后是否触发了预期的表现和数值变化。如果这四件事都能对上那可以视为正常触发。如果对不上就按下面几个步骤去找问题。给日志补上结构化字段后会看到类似这样的内容{ event: COMBO_DETECTED, message: 检测到双果冻双红宝石, timestamp: 1690000000000, frame: 1024, source_ids: [jelly_101, jelly_102, ruby_201, ruby_202], jelly_count: 2, ruby_count: 2 }有了这些字段后面做去重和统计才会方便。只打一行纯文本“检测到双果冻双红宝石”排查时很难定位。2. 先别改代码用四个维度判断触发是否正常2.1 看触发时机和场景对象见到“检测到双果冻双红宝石”后第一件事不是改代码而是看这个日志发生时场景里到底有什么。我会先拉取场景对象列表按类型分组统计。如果当前场景刚好有两个果冻和两个红宝石而且它们都处于 active 状态那么消息本身没有自相矛盾。如果场景里根本没有果冻或者只有一个红宝石日志却打出“双果冻双红宝石”那问题多半出在对象列表维护上旧对象没有移除、对象被错误复用、对象创建时插入了多个容器。这类问题不一定每次发生可能只在某次掉落组合或页面切换后出现。所以排查时不要只跑一次要多跑几个随机种子或者多切几次场景。2.2 看触发次数和帧号事件日志里最好带帧号或批次号。同一个 frame 下同一个组合事件一般只允许触发一次。如果同一帧内出现两次“检测到双果冻双红宝石”需要立刻看事件 key 是否重复。常见原因是检测循环在遍历目标列表时同一批对象被重复命中或者事件队列没有做去重发布端和消费端各打了一次日志。连续多帧都出现同一条事件则优先怀疑状态机没有推进。比如对象已经完成匹配但 state 仍然是 active下一帧检测模块又把它当成有效目标于是再次触发。这种问题比较隐蔽因为日志看起来每帧都新生成一条很像场景里一直有四个目标实际只是旧状态没清干净。2.3 看事件之后是否产生预期结果日志只是检测结果真正重要的是它后面的动作。正常的组合事件应该带动对象状态变化、消除动画、计分或背包奖励。如果“检测到双果冻双红宝石”打了日志但画面没有变化、数值没有增加说明检测逻辑和实际执行逻辑脱节。我会把日志输出和表现回放放一起看。操作方法是先记录帧号然后在渲染调试视图里逐帧检查对应对象的前后状态。重点看被检测的四个对象是否从 active 切到 matched 或 removed如果没有说明检测判断命中了但状态切换没有跟上。2.4 看上下文日志而不是单行单条日志信息量有限。排查时我会把这一帧前后 10 条日志都拉出来看事件来源、入口、有没有异常堆栈。如果前后有加载场景完成的日志说明很可能是开局首次生成时触发如果前后有消除结算日志说明是正常消除后重算触发。结合上下文能快速缩小范围。下面是一个简单的判断表情况判断下一步单帧只出现一次大概率正常验证场景和对象状态同一帧出现两次去重有问题检查检测循环和事件队列连续多帧出现相同事件状态机未更新检查对象状态切换出现时机与场景不符对象列表或配置有误看初始化逻辑和掉落表3. 从配置表、匹配规则和对象状态里找根因3.1 先查输入数据对象列表和掉落配置当事件触发时机不对我最先查的不是检测函数而是输入数据。流程固定为打印当前场景所有对象按类型分组统计和掉落配置比较确认果冻和红宝石应该出现多少个检查初始化逻辑看同一对象是否被 add 到多个容器检查对象释放逻辑看 removed 对象是否还留在对象列表里。常见原因大致有几类。掉落表直接把果冻和红宝石的权重都调高了导致组合出现概率明显上升新手关卡故意同时生成多个目标但事件检测模块没有区分是否是新手指引数据同步后旧对象没有清理对象列表里残留了一帧前的数据。3.2 检查匹配规则和过滤条件很多项目把匹配规则写成一个长 if看起来像这样if len(jelly_list) 2 and len(ruby_list) 2: log(检测到双果冻双红宝石)这种写法最大的问题在于省略了状态过滤和来源标识。只要对象在列表里不管它是不是 active、是不是已经参与过消除都会被统计进去。更稳的写法是先把目标类型和状态过滤掉再做数量判断def collect_active_targets(objects, target_types): result {} for obj in objects: if obj.type not in target_types: continue if not obj.is_active(): continue result.setdefault(obj.type, []).append(obj) return result def detect_events(objects, frame_id): targets collect_active_targets(objects, {jelly, ruby}) jellies targets.get(jelly, []) rubies targets.get(ruby, []) if len(jellies) 2 and len(rubies) 2: emit_event(double_jelly_double_ruby, frame_id, jellies rubies)这里最关键的是is_active()判断。如果不过滤所谓“检测到”其实只是“列表里有”不是“当前画面可交互”。很多诡异日志就是这么来的。3.3 对象状态没有及时更新是最常见根因在合成消除类项目里最麻烦的是状态切换链路。一个对象从 active 到 matched 再到 removed中间可能隔着动画、数据绑定和 UI 更新。很多团队在 matched 之后只改了 UI 层状态没有改逻辑层状态结果下一帧逻辑层还认为它是活物体继续参与检测。于是“检测到双果冻双红宝石”会连续出现多次。处理办法是逻辑层在匹配成功的同时立即把对象标记为 matchedUI 动画只做展示不能倒推出状态。检测模块只消费 active 对象matched 和 removed 对象一律跳过。这样即使动画没播完也不会重复触发组合事件。3.4 用配置开关而不是改死代码去验证为了稳定验证根因我会加一个临时配置项比如force_double_droptrue强制在固定坐标生成两个果冻和两个红宝石。这样可以稳定复现场景而不用靠随机掉落碰运气。确认问题后再关掉配置回归原有逻辑。这个做法比直接改掉落表安全因为它只影响测试环境不会污染正式数据。排查期间还可以把配置放在热更新文件里这样不用反复重启客户端。等根因定位完再决定是修代码还是调配置。3.5 不要忽略异步事件和对象复用如果匹配逻辑和动画、网络回调混在异步流程里可能出现上一帧检测到的对象在下一帧才被真正移除。这时候的“双果冻双红宝石”虽然是历史帧数据但事件队列消费时已经进入新场景容易产生“幽灵事件”。解决方式是给事件带上帧号或场景版本。消费前先判断事件是否属于当前场景旧事件直接丢弃或打到历史日志里不能参与当前结算。异步不是问题问题是没有做事件隔离。4. 设计事件检测方案时把“双果冻双红宝石”当成带元信息的事件对象4.1 不要把组合判断堆在一个 if 里很多项目为了快直接把组合判断写进帧循环的 if。看着简单但后面要支持“三红宝石”“四果冻”时所有条件都堆在一起很难扩展也容易漏状态过滤。更好的方式是把“目标收集”和“组合判断”拆开。目标收集负责从对象列表里筛出当前需要关注的类型和状态组合判断只负责看数量是否达到条件。这样“检测到双果冻双红宝石”就是“收集到两个活跃果冻和两个活跃红宝石”之后自然输出的一条事件而不是某个 if 里的魔法字符串。4.2 事件对象携带足够信息日志文本可以简短但要支撑定位还得带结构化字段。建议事件对象至少包含name事件名如 double_jelly_double_rubyframe_id检测时的帧号用来判断是否重复source_ids命中的对象 ID 集合用来防重复和定位对象targets各类型的数量或对象信息scene_version场景版本或关卡 ID防止旧事件污染新场景timestamp时间戳trigger_type触发来源如开局生成、移动后重新匹配、道具技能。代码里可以这样组织class GameEvent: def __init__(self, name, frame_id, source_ids, targets, scene_version): self.name name self.frame_id frame_id self.source_ids source_ids self.targets targets self.scene_version scene_version self.timestamp time.time()事件去重 key 建议用(frame_id, name, tuple(sorted(source_ids)))。用元组比字符串拼接更安全也方便后续直接传给日志系统。4.3 加一层去重和幂等处理去重不是可有可无而是事件检测的基础能力。最简单实现_emitted_keys set() def emit_once(event): key (event.frame_id, event.name, tuple(sorted(event.source_ids))) if key in _emitted_keys: return False _emitted_keys.add(key) event_queue.append(event) return True这里要注意如果 set 无限增长长时间运行会把内存吃掉。我一般只在调试或回归模式里保留最近 N 帧或者定期清理旧 key。生产环境可以落到 Redis 或数据库里按 frame_id 和事件名做唯一索引。去重逻辑不要等到消费端再处理因为消费端可能有多份订阅各自打印日志重复日志还是会出来。4.4 日志文本和结构化字段分离“检测到双果冻双红宝石”作为 message 可以保留但统计和过滤要依赖 name、frame_id、source_ids 等字段。比如查看“一帧内触发次数”用 frame_id 和 name 分组统计查看“哪些对象重复命中”用 source_ids 找交集。这样排查起来会快很多。好的日志不是够多而是够干净。宁可少打几条也要让每条都能被检索、被聚合并定位到具体对象。5. 复现、验证和回归测试的落地步骤5.1 构造最小复现样例不要一上来就在完整游戏里复现。我会先写一个 mock 场景只往对象列表里放两个果冻和两个红宝石状态都设为 active然后调用 detect_events。预期结果是输出一条事件且只输出一条。如果最小样例就输出两条问题大概率在检测循环或去重逻辑。如果最小样例没有输出则检查过滤条件可能是 type 名不一致也可能是对象状态字段不对。最小样例的价值在于把随机因素全部去掉让问题稳定暴露。只要这个样例能稳定复现后面改代码、验证修复都会很容易。5.2 用固定随机种子和固定操作序列做自动化合成消除类游戏通常有随机掉落或洗牌。直接靠手工点按复现很不稳定随机数一变场景就对不上。我建议在自动化环境里固定随机种子再把操作序列记录下来点击坐标、移动方向、等待帧数、技能触发等。回放时使用同一个操作序列保证事件组合不会因为随机数变化而改变。固定顺序之后还可以加快调试速度先自动跑一组操作记录日志再改成半自动逐帧暂停观察状态变化。自动化负责帮你“复现”逐帧调试负责帮你“定位”。5.3 验证结果要设置明确的判断标准跑完用例后不能只说“好像正常”。我会检查四件事包含组合条件的场景是否恰好触发一次事件事件中的 source_ids 是否存在重复对象同一帧内计数始终为 1事件触发后四个对象的状态从 active 变成 matched 或 removed并且之后不再触发。检查项通过标准失败时看哪里触发次数每条组合事件同一帧最多 1 次去重逻辑、事件队列对象唯一性source_ids 无重复对象列表、复用逻辑状态推进active 到 matched 到 removed状态机、动画回调场景隔离旧场景事件不进入新场景scene_version、队列清理5.4 把“双果冻双红宝石”写进回归用例当问题修复后我会在测试用例里加一条断言def test_double_jelly_double_ruby_detected_once(): scene create_scene(jelly_count2, ruby_count2) events run_one_frame(scene) matched [e for e in events if e.name double_jelly_double_ruby] assert len(matched) 1如果没有满足条件也要断言不触发def test_no_double_jelly_double_ruby_without_targets(): scene create_scene(jelly_count1, ruby_count2) events run_one_frame(scene) matched [e for e in events if e.name double_jelly_double_ruby] assert len(matched) 0这样后续改动掉落配置、匹配规则或状态逻辑都能用 CI 快速拦住。自动用例里造的 scene 要尽量简单不要依赖真实 UI 点击否则稳定性会很差。6. 排查时最容易踩的坑6.1 报错不一定错先看日志级别“检测到双果冻双红宝石”不是 error更不是宕机。如果日志级别是 debug 或 info而且场景确实满足条件那它只是正常反馈。不要一看到组合关键词就去删日志或改条件那样会掩盖真实问题。6.2 “检测到”不等于“出现在画面上”对象列表可能包含隐藏对象、已销毁但未清除的对象、预加载对象、只用于逻辑不参与展示的对象。检测时要区分“列表里有”和“当前可交互”。如果画面上只有一个果冻和两个红宝石日志却打出双果冻先把隐藏对象和残留对象拉出来看。这个坑很常见也是最容易误判的。6.3 不要一上来就调掉落概率和数值新版本突然频繁出现组合事件很多人会想到“是不是概率太高了调低点”。但概率变高只是表现根因可能是掉落配置受热更新影响、权重表重复、关卡难度使用错误也可能是匹配规则把两次检测当成一次。先查根因再调数值。概率不应该是第一怀疑对象。6.4 调试日志本身会影响性能在帧循环里高频打印事件 JSON序列化和 IO 都会拖慢帧率。尤其当“检测到双果冻双红宝石”连续刷屏时日志写入可能让 Bug 更难复现。我的做法是调试时打开完整日志回归测试时只记录事件计数和抽样日志上线时把事件日志降级为计数器或采样上报。日志是为了定位问题不是给生产环境增加负担。6.5 日志字段清晰度比数量重要哪怕只打一条日志也要让人能看懂。最差的一条日志是“检测到双果冻双红宝石”后面什么都不带。至少要带上 frame_id、事件名、source_ids 和场景版本。有了这些字段后续不管在日志平台还是本地文件里都能做聚合分析。没有字段的日志数量再多也只是噪音。6.6 对“双”的定义要统一“双”是“等于两个”还是“至少两个”产品、策划、开发、测试可能理解不一致。比如场景里出现三个果冻和两个红宝石该不该打“双果冻双红宝石”如果不统一有人写 2有人写 2就会出现“测试觉得正常开发觉得 bug”的矛盾。最好在需求文档里明确组合事件的定义并用测试用例固定下来。这个细节不算技术难点但在实际项目里最容易扯皮。最后说下我的个人习惯。遇到类似“检测到双果冻双红宝石”的组合事件日志我不急着改代码也不会删日志。第一反应是先把日志当成信号看它出现的帧号、对象来源和后续状态变化第二反应是确认是否重复第三反应才是查配置和数值。多数情况下真正的问题不是事件名称本身而是事件背后的对象状态、去重逻辑或数据初始化没做好。把这些基础字段补全后面的排查会轻松很多。如果你的项目最近也在为“明明没这个组合却打印出来了”或者“同一事件反复出现”发愁可以直接把这套排查顺序用起来。