OpenFront 可跳转回放查看器（v0.35.0）：如何开启、跳转到任意时刻、不用重看整场来复盘

直接答案：在设置里打开“New Replay Viewer”，然后打开任意一局结束的对战即可跳转

v0.35.0 的发布把“从头线性看”的回放换成了可跳转的查看器，而且它是可选功能：开关关着的时候，“Watch replay” 仍然打开经典回放，绕过去的唯一入口就是设置菜单里的 New Replay Viewer 开关（它读取 settings.replayViewer，默认关闭）。一旦打开，你从游戏历史里打开的每局结束的对战都会进入查看器。它的原理是：查看器会在你的浏览器里、在游戏引擎自己的 worker 上把录像档案处理一次——和直播对战用的是同一个 worker——经过这一次之后，时间轴上的每次跳转只花大约 20 毫秒，因为整局游戏已经被解码完、躺在本地内存里了。键盘控制刻意做得极少：空格切换播放与暂停，右箭头和左箭头各进退一帧，按住 Shift 一次跳 100 帧。速度菜单提供 0.5 倍、1 倍、2 倍、4 倍、8 倍、16 倍和 32 倍。还有一个直接链接形式 #replay-viewer=<gameID>，即使开关关着也能打开查看器——这就是你可以把一个直接落到可跳转视图的链接发给别人的方式。这个功能没有任何部分跑在服务器上；服务器只提供存档录像。如果你只从这一页带走一个动作，就定为：把开关打开一次，从历史里打开一局长局，并让处理过程跑完再下判断——第一次打开按设计是慢的，之后在同一台机器上再打开同一局几乎是瞬间完成的，因为处理好的回放会存进 IndexedDB。开始之前先摆正一个预期：查看器是一件复盘工具，不是观看直播对战的新方式。它只对结束的对战生效，它增加了旧路径没有的处理步骤，而且它会向浏览器要真实内存——存储把解码后的档案限制在 256 MB，以保护低配设备，一局大到超出实用预算的对战在机器已经吃紧的会话里就是不会解码。换句话说，你并不是白拿跳转：作为交换，你接受每局每台机器一次的处理过程，这一页其余部分正是把这笔交换讲清楚。

版本边界：v0.35.0 改了什么、没改什么，以及查看器仍停在哪

在 v0.35.0 之前，一局结束的 OpenFront 对战只能靠重跑直播回放路径重新打开：你通过网址或从大厅加入那局已结束的局，客户端按你当初直播观看时的速度实时重放它。这带来三个结构性限制。第一，它是线性的——你不能跳到一个九十分钟局的第四十分钟，只能把前面四十分钟等过去。第二，它没有速度控制；回放以模拟运行的速率运行。第三，它没有任何完整性校验，你只能照单收下录像。v0.35.0 把三点全改了：录像现在被处理成编码帧，时间轴完全可跳转，速度菜单从 0.5 倍到 32 倍，处理过程会校验直播客户端约定的哈希检查点，遇到第一处不一致就停下。v0.35.0 的发布还把回放 worker 本身从 815 KB 减到 340 KB，把回放处理挪到引擎自己的 worker 上。v0.35.0 没有改的是确定性边界：核心模拟只在同一个 build 内是确定性的，所以一份录像只能完整重放在产生它的那个 build 上。来自其它 build 的录像会被路由到那个 build 的版本壳 replay.<domain>/<gameID>，和版本说明里描述的 v0.33.6 版本化回放机制处理的方式完全一样。落到实践上就是：在主站上，一局很老的对战可能仍能打开（通过壳或存下来的副本），但一旦录像所属的 build 在任何地方都不存在了，那局就没了——查看器不会复活录像，它只是让仍然可用的那些变得好看得多。“Catching up…”（追赶中）这种在直播时的行为完全是另一回事：它是确定性模拟在卡顿后追上服务器的行动流，不是回放功能，查看器也不碰它。这一页上的所有控制值——256 MB 上限、每秒 10 tick 的速率、速度列表、±1/±100 帧步进——都读自 v0.35.2 标签源码，也就是 v0.35.0 之后只改了些小修补的同一套回放代码：v0.35.1 与 v0.35.2 的发布都没有改动回放行为，所以这里描述的控制对整个 0.35 系列都成立。

决策框架：什么时候查看器划算，什么时候经典回放仍然够用

第一个决策很简单：如果你经常重看对战以找出某个决策出错的瞬间，查看器立刻回本，因为旧流程里最贵的一步——等你已经知道的那些片段——被直接删掉了。查看器就是为社区 2025 年反复追问的那个复盘问题而造的：“能不能跳到那个时间点？”第二个决策是关于什么时候打开回放，而不是要不要打开。处理是每局、每台机器、每个 build 一次：第一次打开一局长局要付一次处理过程——文档基准里 26 分钟 25 人局约 70 秒，而且这一步发生在你的机器上，不在数据中心——而之后每一次打开都命中缓存，从 IndexedDB 加载存好的帧、几乎瞬间打开。所以理性的流程是：在你能拿到的最好机器上把一局处理一次，然后从任何地方自由跳转，包括手机——手机上存好的回放会加载而无需重新处理。第三个决策是关于存储预算。存储在所有已存回放合计上封顶 256 MB，淘汰时先丢最近最少看的；基准那局约 24 MB，所以上限大约能装十几局长局，超出后旧条目会随着你看新的被悄悄清掉。如果你一周只复盘几局，上限永远不会咬到你；如果你把每局都当复盘材料，就要预期你最老的已存回放会过期、等你回头时再被重新处理。第四个决策是关于你不需要做什么：你不必保存文件、不必导出任何东西、不必开着标签页——回放处理完就自动入库，而一个始终处理不完的回放（比如被不一致截断的）就是不被保留。经典回放在恰好两种情况下仍是正确工具：当你想在低配机器上要一条依赖最少的路径（它不跑校验过程），以及当你看的是一局很老、录像很快就会停止被托管的对战（经典路径能通过壳打开它、牵动的部件更少）。其余所有情况，查看器在复盘上都严格更好。

场景一：3 小时的 25 人 FFA——不重看三小时找到一次背叛

假设社区 2025 年 11 月帖子描述的局面：一局很长、人数很密的 FFA，打了远超两小时，末尾出现崩溃，你怀疑是某个特定盟友背信。用经典回放，你的复盘成本是整局时长在 1 倍下——约三个小时的实际时间，或者干脆没有速度控制全靠耐心。用查看器，账就变了。从历史打开这局结束的对战；查看器取回存档录像，在引擎 worker 上启动处理过程。对这种长度和人数，处理过程在现代机器上要大约一到两分钟，从文档里 26 分钟 25 人局 70 秒推上去；处理期间时间轴未处理的尾段显示为灰色，跳进灰色会弹回——所以在处理完成前别试着往前跳。处理完成后，整条时间轴都活了。你从结尾入手：把速度设到 16 倍或 32 倍，从终点往回扫，以十分之一的成本盯住领土和单位数量，直到崩溃窗口出现；关键交锋降到 1 倍；用空格把一帧按住、边读单位数或旗帜边看，当单步没够到时刻时用 Shift+左箭头退 100 帧——按每秒 10 tick 的速率也就是十个 tick。这么大的局，存好的回放会落在几十 MB 量级，远在 256 MB 预算之内；具体数字取决于地图、时长和事件密度，但基准给了你尺度：长而忙的局真占存储，短局几乎不占。你现在能回答、之前却回答不起的复盘问题是一个因果问题——哪一个决策、在哪一分钟做出的、导致了崩溃——而答案以分钟计而非以小时计。这就是整个产品在一个流程里：处理一次、快扫、慢看、确认那一帧。

场景二：移动端第二遍——电脑上处理、第二天早上在手机上跳转

第二个场景打破了旧版本锁定痛点的模式，而这个模式正是 2025 年 11 月帖子描述的东西：一天录下的局，第二天就看不成了，因为网站更新了。你在电脑上的前一天晚上结束一局竞技团队赛，查看器已开启，打开一次让处理完成、回放落到这台机器的 IndexedDB 里。第二天早上你在手机上，想核对一次穿插。如果录像所属 build 还是当前的，手机上 openfront.io 打开同一局会跑它自己的处理过程——IndexedDB 存储是按设备隔离的，电脑的缓存不会跟着你走——然后跳转就可用了；在手机上，一局典型团队赛的处理短但不为零，所以打开一次、让它跑完再跳。版本边界这时开始起作用：如果夜里网站更新落地、录像所属 build 不再是当前版本，主站会把录像路由到它的版本壳，而壳保留旧 build，让回放仍按旧规则打开——就是 2025 年 11 月帖子在 blue.openfront.io 上发现的那个机制，现在推广到 replay.<domain>。实操规则：对一局你明知道第二天早上要看的，同一晚在你最好的机器上打开它，在任何更新落地之前，录像就被固定到一个你确认存在的 build 上。如果更新已经落地，就去查壳是否还在托管那个 build——非常老的 build 迟早停止托管，到那时无论新旧客户端都无法处理录像，那局就不可恢复。把版本壳当成宽限期，而不是保险库。还有一个本场景专属的边界：校验过程检查的是直播客户端记录的哈希，多人时节奏是每 10 回合一个检查点，所以团队赛的多人生回放被密集地校验——而一旦录像缺了哈希到达，查看器会在屏幕上标出，回放被标记为未校验。因此如果你复盘的是一局自己录的团队赛，把网站版本记进你的复盘笔记：这是你之后能判断录像是否仍可校验、这局是否仍受哈希保护的唯一信息。

失败模式与对策：什么会坏，以及怎么办

第一个失败模式是 build 不匹配，也是最常让回放“打不开”的原因。录像只能完整重放在产生它的 build 上；查看器在做重活之前会检查这一点，其它 build 直接送去版本壳。对策：理解“回放停了或被重定向”几乎总是版本问题，不是游戏损坏。在主站上，如果录像所属 build 在被托管，壳会打开它；如果 build 已从托管消失，客户端一侧没有任何东西能找回它，所以唯一对策在上游——趁它的 build 还在被托管时打开并处理回放；如果你是那种会归档对战的玩家，在分享链接的上下文里记下 build。第二个失败模式是处理中途哈希不一致，意思是你取回的录像和直播客户端校验过的并非逐位一致。处理过程在第一处不一致处停下，而按构造，查看器已经发给你的一切仍是对局真相——帧只有在后面某个检查点匹配后才会被交付——所以可见结果是时间轴提前结束或一次跳转弹回，查看器会告诉你回放被标记了。对策：别把被截短的时间轴当成渲染 bug；那是完整性检查在干活。如果一份本该干净的录像反复失败，就重新取回一次；服务器上的录像才是事实来源，短暂的取回故障比引擎损坏更可能。第三个失败模式是存储压力：256 MB 上限加上“最近最少看”的淘汰，意味着你最老的已存回放会随着你看新的而悄悄消失。没有按局固定的手段，所以对策是流程而非设置——哪局回放要紧，就在它还在时复盘它，并留一份游戏 ID 和链接，以便日后从录像重新处理。第四个失败模式是分块加载回退：如果查看器自身的延迟加载失败，页面会退回经典回放，所以当一个打开“看起来不一样”时，第一反应是看控制台、然后重新加载。

播放控制：完整的键盘与速度参考

查看器是键盘优先的，整个控制面小到可以放进一张表。底层处理速率是每秒 10 tick，所以一帧就是模拟的一个 tick——十帧是一秒真实对局时间——下面每个跳转、步进和速度都以它为基准。

输入	效果
空格	播放 / 暂停
右箭头	前进 1 帧（按住 Shift 进 100 帧）
左箭头	后退 1 帧（按住 Shift 退 100 帧）
速度菜单按钮	选 0.5、1、2、4、8、16、32 倍

几条说明让这张表可用。第一，帧步进是精确的：按每秒 10 tick，单独一次右箭头是十分之一秒对局时间，Shift+右箭头是十秒对局时间——100 帧这个常数就是为了让你按住 Shift 几次就能扫过一段有意义的区间。第二，按键在设置菜单打开时被刻意忽略——发布说明把这列为一个修复，这样在查看中途找开关不会误扫时间轴。第三，速度是相对真实时间的倍数，所以 32 倍是把每秒 10 tick 的模拟按每秒 320 tick 播放；渲染和解码帧跟得上，但把 32 倍当成“找哪里发生了事”的扫描速度，别当成能读单位数的速度。第四，跳进未处理的尾段不是需要惊慌的错误：尾段之所以是灰色，正因为它还不存在，跳进去会弹回最后已处理的帧。正确做法是让处理跑完再跳。第五，因为播放状态只属于查看器页面，中途关标签页会丢播放头但不会丢工作——存好的回放仍在 IndexedDB，下次打开从头开始、帧即时可用。第六，同样的按键在设置浮层里也是失效的：发布说明专门修了“在找开关时按了跳转键、悄悄把菜单后面的时间轴扫走”这个情况，所以如果你的方向键看起来没反应，先查是不是还有一个设置面板开着，关掉它再扫。第七，速度选择在一次会话里是粘性的——关掉设置菜单不会重置它——这对“32 倍扫、再降 1 倍看”的模式很方便，只有在你忘了自己还留在 32 倍时才碍事；当一个回放看起来在飞而你并没选择加速时，先查速度菜单。

模式与地图调整：FFA、团队和单人各自拿到不同的价值

查看器跨模式是统一的，但每次打开的价值不统一，因为复盘问题不同。在 25 人 FFA 里，并发事件密度最高、时间轴最长：这么多玩家的局每秒产生的状态变化更多，所以处理过程最重、存好的回放最大、跳转的回报也最大——重点就是在吵的局里找到一条线。用 16 倍或 32 倍扫，只在找到的窗口内降到 1 倍。在团队模式（1v1、2v2、4v4）里，局更干净、复盘问题通常偏战术：一次具体的落地、一次具体的穿插、一次具体的核弹发射。帧级步进在这里是正确工具——10 帧是一秒真实时间，你能精确落在那一瞬间、逐 tick 看后续——而且回放在处理时间和存储上都更省，意味着你更能负担得起复盘更多局；256 MB 上限能装下比 FFA 多得多的团队局。在单人里，两件事变了。哈希节奏更粗——每 100 回合一个检查点而非每 10 回合——所以完整性检查更稀，回放的尾段（最后一个已记录哈希之后的帧）没有任何东西可对照；文档明说这些结尾帧是照原样发送的，实践上至多也就是最后几秒。单人的第二个变化是“录像”可能来自你自己的 run，所以“未校验”标记更可能是真实的数据缺口而非取回故障；当你在自己的单人回放上看到未校验提示时，重新录一遍这个 run，别信任存好的帧。地图大小在模式内部也有影响：一张有长贸易路线的大地图比同时长紧凑图产生更多事件历史、更大的存好回放，所以当你接近存储上限又在复盘大地图 FFA 时，第一件该做的事就是通过看更新、更小的回放来清理。这些都不改变控制——同一张表到处适用——它们只改变你的复盘时间最好花在哪。跨模式的一个习惯来自存储这笔账：团队局回放更省，就更该常处理它们，把存储预算留给真正值得的高密度 FFA。

复盘流程：把查看器变成一套可重复的赛后习惯

查看器是一件证据工具，让它回本的习惯是一套你对每局重要对战都跑的五步固定流程。第一步：把开关打开一次——设置里的 New Replay Viewer——然后再也不用想它；一次性直接链接形式 #replay-viewer=<gameID> 是你把可跳转视图分享给任何人的逃生门，包括开关关着的人。第二步：同一晚从历史打开这局结束的对战，让处理过程在你最好的机器上跑、让回存在 build 确定在线时入库——这一个习惯就是针对“版本锁定”痛点的全部防御：一局好局在夜里一次更新后变得看不了。第三步：让处理跑完再跳，把灰色尾段当进度指示；如果你赶时间，团队局处理很短，你可以先退出去再回来——存储会替你记着。第四步：快扫、慢落：16 倍或 32 倍找窗口，1 倍读它，空格按住一帧核数字，Shift+方向键移动十秒的块——并把你关心的那一瞬间的帧号或时间戳写下来，因为播放头活不过关标签页。第五步：把那一瞬间变成一个可测的改动，在下局之前做，这正是回放复盘指南所固化的复盘方法：在你刚定位到的那一刻找到第一个被打破的假设，然后在下一个大厅里改一件事。最后一步正是把查看器和视频播放器区分开——跳转存在是为了回答“那个决策为什么在那一秒失败了”，而这个答案只有改变下一个大厅时才有用。如果你的复盘问题是关于你整体怎么打而非某一局，更宽的控制面在快捷键指南里，直播侧的习惯在那里；这一页管的是赛后侧，从一局结束的那一刻到你有一个可测试的“下一局要改什么”的那一刻。