——在不讲理的工具里，如何给事件硬塞确定的顺序
别急着鄙视 Axure，它本质上就是一个没有函数、没有数组、还是单线程异步执行的沙盒环境。在这个沙盒里，我遇到了一堆极其硬核的系统底层 Bug……
我在 Axure 手搓《ChiTank - 终章 2026》这个坦克大战原型时，我遇到过无数个让人抓狂的“灵异事件”：
比如子弹飞出炮口后，突然掉头朝自己飞过来；比如敌方的坦克重生时，直接卡进了墙里；再比如我刚扔出一颗手雷，准备团灭三辆敌坦，结果系统卡了一下，只有一辆坦克爆了。
你以为是逻辑写错了？我去查了底层的交互，逻辑完全闭环，没有写错任何条件。最后我发现，所有这些看似不相关的 Bug，根因全都出在“时间”上。
Axure 的执行引擎是单线程、异步、且极其不可控。它没有给你提供任何精确的“时间控制”API。当高负载时，它的事件执行就会像早高峰的十字路口，发生严重的拥堵和错位。为了破解它，我摸索出了一套《Axure 时序控制方法》。
Axure 手搓坦克大战原型，PC 端浏览器打开就可以直接玩http://www.guochi.org/ChiTank/
一、 跨层时序：延时初始化
（游戏现象：开局敌方坦克没刷出来，或者重生在了墙里）
Axure 的“载入事件”在同一帧内是同时触发的，谁先谁后全凭系统心情。如果你的坦克元件先执行了，而读取地图数据的元件还没执行完，坦克读到的坐标就是“空值”。
我的解法：延时初始化。把所有的载入事件“做薄”，只让它做两件事：等待，然后触发伪事件（我的另外一篇姊妹篇有详细拆解「伪事件」）。把真正的复杂逻辑“做厚”，全部放到伪事件里。强行让所有元件等 100ms，站稳了再执行。
【载入】： 等待 100ms 触发事件 → 【初始化】 【初始化】（伪事件）： 1. 初始化地图数据（MapStr） 等待 1ms 2. 初始化碰撞图 等待 1ms 3. 初始化敌方坦克二、 同层时序：并发间加等待
（游戏现象：吃手雷时，本该炸毁的敌坦卡住没死）
同一帧触发的多个事件会产生冲突，系统的处理往往是“漏算”。比如团灭 3 辆敌坦，系统可能只处理了 1 辆，剩下 2 辆被悄悄吞掉了。
我的解法：并发间加等待。在并发事件之间，人为插入 1ms ~ 10ms 的等待时间。这1 毫秒，足够让 Axure 的内部调度器喘口气，把前一个事件彻底执行完。手雷团灭、火花炮口 Bug，全是用这 1ms 强行错开执行窗口，从而彻底解决的。
并发执行的时序冲突与 Wait 补偿模型
三、 官方验证：这不是“野路子”，而是唯一解
关于“并发加等待”，我专门和 Axure 官方有过一次深度的邮件交流。
我向官方反馈了事件并发时漏算的问题。官方的回复非常坦诚：他们承认在某些情况下会发生“意想不到的行为（unexpected behaviors）”，并明确建议“在每个交互之间添加 Wait（等待）动作”，以确保顺序执行。
我告诉官方，这正是我多年来一直采用的做法。工具本身并没有完美解决异步执行，把这个坑留给了使用者。而“硬塞时序”，就是当前唯一正确的破局之道。
四、 补偿与“非受控滑步”治理
（游戏现象：子弹突然反向飞，或者坦克的轨迹像打滑一样漂移，看似两个完全不相干的问题）
这是最玄学的一个坑。查了几天逻辑完全无误，最后发现是非受控滑步。
原本，我给坦克的监听周期设了 275ms（步进动画是 300ms）。我以为留了 25ms 的安全垫，但过大的余量，导致监听在步进尚未完成时就触发了，读到了半途的旧状态。单次无害，长期积累，就形成了漂移。
后来我做了“性能探针”量化后发现：工具的实际执行延迟大部分时候只有 1.5~9ms。我把 275ms 改成了 290ms（只留 10ms 余量），子弹的余量改成了 1ms。问题瞬间消失。
| 表现症状 | 根因 | 解法（V8.3定稿） |
|---|---|---|
| 子弹偶发掉头 | 监听周期（275ms）远短于 步进周期（300ms），读取了半途状态 | 监听周期改为290ms 只留 10ms 余量。 （子弹仅留 1ms） |
| 敌坦重生位置失控 | 同上 | 同上 |
五、 架构级避坑：错峰避免共振
（游戏现象：满屏子弹和敌方坦克时，游戏突然卡成 PPT）
这是整个项目中，最具“系统科学”美感的一次优化。
我的游戏里有 20+ 个高频循环（子弹、敌坦、道具等）。如果它们的周期都是整数倍关系，它们就会在特定帧发生“共振”，瞬间把 CPU 跑满。
系统负载共振与错峰规避模型
正如上图所示，错峰前，20+ 个系统会随着时间推移不断叠加，最终在峰值处发生雪崩。而错峰后（我把周期设为互质数），系统总负载被彻底摊平，系统最高峰值永远只等于单个最重事件（Max）的负载。这就是数学在架构设计中的降维打击。
六、 更隐蔽的坑：异步抖动与接触事件
- 异步抖动严重：我原本设的 16px 护城河（子弹不进墙带不检测）不够。因为异步抖动，理论安全余量在实际运行中根本不够，最终加宽到 32px 才稳定（目标单元宽度的 2 倍）。
- 接触事件只在移动开始时判断：Axure 中想做“一步到位”的射线检测根本不可能，逐格步进才是唯一可靠的方案。
《ChiTank - 终章 2026》演示效果
七、 知识体系全景图
| 核心命题 | 给事件精确硬塞时序，覆盖不可控的执行 |
|---|---|
| 核心问题 | 事件顺序不确定、异步滞后、并发漏算、变量读取错位 |
| 一横（跨层） | 延时初始化：载入层做薄，伪事件层做厚。用 100ms 等待隔开所有依赖，消灭载入顺序的随机性。 |
| 一纵（同层） | 并发间加等待：同帧多事件必须加 1~10ms 等待。拆分并发，建立明确的先后顺序。 |
| 一补偿 | 提前量等待：用提前量抵抗异步抖动。余量限制在 1~10ms，过大反而引发“非受控滑步”。 |
| 架构级避坑 | 错峰避免共振：设置互质周期，削平并发峰值。 |
| 边界与包容 | 时序只能解决执行问题，解决不了逻辑错误。逻辑正确 + 多次优化 + 极其偶发 = 包容原则。 |
结语
Axure 没有“时间”，只有“等待”。比起死磕逻辑，找对“时间差”，才是破局的关键。
姊妹篇：逻辑与时间的双维解法
《Axure RP 逻辑组织方法——用伪事件模拟程序结构》
如果你也在用 Axure 挑战复杂系统，你会发现光有“时序控制”是不够的。时序解决的是“代码对，但会出 Bug”；而《逻辑组织方法》解决的是“逻辑太多，一团乱麻”。
| 维度 | 姊妹篇（逻辑组织 F001） | 本篇（时序控制 F002） |
|---|---|---|
| 核心问题 | 逻辑太多，一团乱麻 | 代码对，但偶发 BUG |
| 解决维度 | 结构 | 时间 |
| 核心手段 | 伪事件 + 来路分派 | 等待 |
| 读者痛点 | “怎么组织这么多逻辑” | “为什么偶尔出错” |
全文完
本文基于《终章 2026》ChiTank · Axure RP 坦克对战原型的实际开发经验整理。
项目作者：郭池（www.guochi.org）
文档日期：2026-10-09
⚠️ 版权声明：本文首发于「人人都是产品经理」及「郭池」个人专栏。基于 ChiTank《终章 2026》项目实战复盘，欢迎转发，洗稿必究。
