商业框架里已经有其中相当一部分。关键是分清它们修改的是显示、预测状态、执行时刻，还是玩法规则。一个 SDK 提供 RPC 和属性复制，只说明消息能传过去；要做到低延迟体验，还需要输入历史、时间管理、重算、历史查询和发送预算。
分类沿用 2022 综述 §4；下面的操作步骤与数值例子是本文的工程化解释。框架能力见下一章官方资料，研究分支没有强行标成商业默认功能。
先让人知道操作已发生，或说明网络正在变差。不改变权威世界。
利用本地输入、历史运动或多个候选未来，在消息到达前生成可显示的状态。
有时等一等，有时查过去。管理不同机器的时间差，而非缩短传播距离。
放宽操作或命中条件。它可能改善可玩性，同时改变原本的竞技规则。
解决：开枪、互动、技能启动等待服务器时的“按了没反应”。
做法：按键时立即播放枪口火光、后坐力或准备动画，生成本地事件编号；请求同时发给服务器。返回结果后再确认伤害、消耗与奖励。若失败，取消尚未确认的效果。重放同一输入时用事件编号去重。
代价：已播出的声音不能收回，故即时效果与最终胜负需要不同确认策略。这与“立即模拟角色位置”的自预测不同；两者可以一起用。Unity NGO 的 anticipation 提供相近的先反馈、后校正构件，但具体技能效果仍由游戏编写。
综述 §4.1.1；NGO 的 anticipated / authoritative 两份值。
解决：玩家把网络延迟误认为操作无效或游戏规则失灵。
做法：统计 RTT、到达间隔与快照年龄，显示网络图标、数值、待确认标记；研究中也有“影子位置”或不确定区域。RTT 低但快照老，应暴露后者，而不是只显示绿 ping。
代价：它提升可解释性，不提高命中精度或减少传输时间。框架可提供测量数据，什么时候显示给玩家是产品决定；本次没有核实任何框架默认提供综述中的全部不确定区域可视化。
综述 §4.1.2。
解决：自己的移动要等一次往返才响应。
做法：为输入编号并记录步长 → 本地执行 → 发给服务器 → 收到“已执行到编号 k”的状态 → 恢复该状态 → 重放 k 之后的输入 → 平滑显示误差。服务器验证的是移动规则、速度和碰撞，而非相信客户端最终坐标。
真正需要框架管理的东西：输入环形缓冲、状态历史、过期确认、重放顺序、预测作用域和一次性效果。角色冲刺会影响移动时，冲刺状态也必须进入这条历史，不能只复制一个布尔值。
实现入口：UE CharacterMovement 的 SavedMove；Fusion Unity 的网络 tick；Unity Entities 的预测系统组。代价：碰撞依赖越多、延迟越大，重算越贵。不是所有对象都必须预测。
解决：远端玩家每收到一次消息就跳一下。
做法：按服务器时间戳收集快照；选一个稍旧的显示时刻 t；找到包围 t 的两份状态，再按时间比例插值。朝向可用四元数插值；位置有速度时可用 Hermite，但需要防止越过障碍或曲线过冲。
动态缓冲：记录消息到达的抖动分布，选择覆盖大部分抖动的缓冲；持续欠载时扩大，网络恢复后逐渐缩小，避免显示时间突然倒退。发生传送或重生时应清理历史，不能横跨整张地图插值。
代价：更平滑但更旧。框架插值通常负责网络时间轴；每帧固定比例 lerp 只是追赶滤波。Fusion 2.1 已公开基于抖动分位数的配置，见下面算例。
解决：最新状态已经过时，或丢了一两次更新。
做法：从时间戳 t₀ 的位置、速度出发，计算 x(t)=x₀+v₀Δt；可靠的加速度模型可加 ½aΔt²。设外推时间上限，超限后冻结、减速或扩大缓冲。新状态到了再纠正误差。
为什么不是万能：匀速车辆好猜，突然反向、被撞、跳跃结束与新障碍都可能猜错。只在当前世界射线检测，并不能推导过去发生的碰撞。学习型状态预测也是“如何补缺失状态”的一种模型选择，不必先上神经网络。
商业对应：UE 的部分网络物理模式、Fusion Forecast 都利用状态与速度进行前推/纠正；它们不等于每次恢复整段历史的 resimulation。选择时要看物理交互需求。
综述 §4.2.2.2；物理的两条路线；MPAI-SPG 是学习型补状态的研究例子。
解决：云端要等玩家输入再模拟和渲染，整个链路才开始工作。
做法：当前输入尚未知时，先计算“向左 / 向右 / 不动”等分支，准备相应状态或图像；真实输入到达时选择匹配分支，其余丢弃。覆盖不到的输入再走纠错路径。
代价：连续输入与多个玩家会导致分支组合爆炸，消耗额外计算和带宽。综述主要举 Outatime。不要把普通“保存过去，猜一个未来，错了重算”的 rollback，叫成同时预算多条未来。
商业状态：本次核实的框架文档没有证明它们默认采用这种多分支云渲染方案；不能因为都叫 prediction 就画上勾。
综述 §4.2.3，PDF 第 18 页。
解决：消息来晚时，直接在“现在”处理会与玩家所见冲突。
做法有两种：一是恢复检查点、插入晚到的真实输入并重算后续帧；二是保存历史命中盒，只对历史做命中查询，不重演整个世界。两者都要校验时间戳、限制历史窗口、避免副作用。
商业对应：Quantum 是确定性预测/回滚；Fusion Unity Host/Server 有 Hitbox 历史查询。二者保存的状态、权限和最后做的工作不相同。
代价：历史内存、重算 CPU、可撤销事件，以及“躲进掩体后中枪”的取舍。框架能提供机制，不能替设计者确定公平窗口。
解决：输入到达时间不同导致大量预测错误、执行不同步。
做法：立即发送本地输入，但安排到未来第 k+d 帧执行；或把收到的消息放入时间桶，按统一时刻应用。显示端的快照缓冲也是延后消费消息的相关做法，不能把执行延迟与显示延迟混成一个参数。
例子：60Hz 下人为等 2 帧约 33ms，可让这段时间内赶到的真实输入替代猜测。若晚到 5 帧，只覆盖了其中 2 帧，仍可能需要重算。
商业对应：Quantum 的输入延迟设置；Fusion 2.1 可让客户端用额外输入延迟约束重算数量。代价：本地操作晚开始，应与 CPU 峰值、纠正频率一起衡量。
综述 §4.3.2.1；Quantum 配置；Fusion 时间策略。
解决：某些公平性规则要求不同网络条件的玩家尽量同时看到事件。
做法：同一更新，先发给慢链路，晚些发给快链路。假设可准确估计单向延迟，目标到达时间为 T，则每个连接的发送时间为 T−估计传输时间。设最大等待上限，防止全体被最慢连接拖住。
代价：主动牺牲快连接的响应，且单向时间估计与抖动会破坏对齐。普通打包等待可能也延迟发送，但目的不一定是公平性。本次未核实所列 SDK 默认启用按玩家 ping 均衡的发送延迟。
综述 §4.3.2.2，PDF 第 21–22 页。
解决：玩家指向的是旧目标位置，精细瞄准难度变大。
做法：在合适范围内降低准星移动增益、让准星跟随目标，或修正弹道靠近目标。要限制作用距离、角度、目标选择，并按统一规则在权威端验证。
与命中回溯不同：回溯询问“过去这条射线是否命中”；控制辅助修改输入或射线，使其更易命中。商用游戏可以有瞄准辅助，但这不证明它是按网络延迟动态启用。
代价：改变技能要求与竞技平衡。综述中的许多实验研究本地系统延迟或鼠标操作，并不是公网多人验证；通常属于游戏玩法层，非通用复制器自动解决。
综述 §4.4.1。
解决：坏网络使原来的反应窗口、目标大小或移动速度过于苛刻。
做法：放大有效目标、降低游戏速度或延长动作有效时间。例如将判定半径 r 调整为 r+ε，实际上是更改判定规则，而不是恢复真实历史。调整幅度必须有上限，并防止不同系统重复补偿。
代价：可玩性可能改善，但玩家之间可能适用不同规则；若直接奖励高延迟，还可能出现人为制造延迟的激励。不能因为某游戏命中盒较宽就宣称它使用了延迟自适应属性调整。
商业状态：引擎允许你编写这些规则；本次没有证据表明所列网络框架默认执行综述这种按延迟调属性的策略。
综述 §4.4.2。
不在这 11 个叶节点里，却同样影响低延迟：AOI、优先级、增量压缩、输入冗余和发送节奏。它们主要控制“发送哪些数据、用多少带宽、何时送达”。带宽队列一旦堆积，再好的预测也只能补越来越旧的信息。
这里比较的是公开文档可核实的机制，不是广告里的“低延迟”标签，也不是商业游戏采用率排名。版本口径：Fusion Unity 2（部分时间策略限 2.1）、Quantum 3、Unity NGO 2.13、Entities 1.10，以及 Epic 当前在线文档。Godot 版 Fusion 3 单列为开发预览。
| 框架 / 组件 | 提供的机制 | 如何接入 | 不能自动得到 |
|---|---|---|---|
| Photon Fusion Unity 2 | Host/Server 的预测与重演；快照插值；历史命中盒查询 | 网络 tick 中写模拟；注册输入与网络状态；配置 Hitbox | 任意脚本可安全重放、任意物理成本可接受；Shared 模式同等能力 |
| Photon Quantum 3 | 确定性模拟、确认输入、预测/回滚、verified / predicted 帧 | 用 Quantum ECS 与确定性库写玩法 | 把已有 Unity/Godot 非确定性物理原封不动搬进去 |
| Unreal CharacterMovement | 角色移动预测、保存移动、权威校正、重放与网络平滑 | 使用/扩展 CharacterMovement 与 SavedMove | 全部技能、刚体世界和射击命中都自动回溯 |
| Unity Netcode for Entities 1.10 | 预测 Ghost、输入与 tick、重演系统组、逐对象预测选择 | 预测逻辑加入 ECS 系统组，正确处理 Simulate 标记 | 普通 MonoBehaviour 自动加入历史重算 |
| Unity Netcode for GameObjects 2.13 | Anticipation：预期值与权威值分离、过期数据处理、平滑 | AnticipatedNetworkVariable / Transform；自己写请求规则 | 完整的输入历史 + rollback-and-replay 循环 |
| Photon Fusion Godot 3 预览 | Client-Server 输入队列、预测重置与重演；远端平滑；Forecast 物理路线 | Godot 4.6+ GDExtension；FusionServerReplicator | 生产成熟度保证，或 Unity 版所有功能已移植的保证 |
| Godot 原生 / netfox | 原生提供复制与传输构件；netfox 补充回滚历史、输入延迟与冗余等 | 原生自建时间层，或接入插件的回滚回调 | 通用确定性和完整刚体状态恢复的自动保证 |
在 FixedUpdateNetwork() 里处理 tick 输入和模拟；客户端先预测，服务器快照到达后以权威状态为基础重演。渲染读取模拟状态之间的插值。这里的价值是框架统一管理时钟与重演，而不是开发者到处手写独立的 lerp。官方模拟循环。
射击则是另一条路径：给对象配置 HitboxRoot 与 Hitbox，调用 Runner.LagCompensation 查询历史。可用 sub-tick 选项对客户端当时看到的两个 tick 之间状态查询；历史长度可配置。官方限制是 Server / Host 模式。这不会消除目标与射手之间的公平性冲突。官方命中补偿。
Fusion 2.1 文档公开了按抖动分布选缓冲、允许一定比例迟到快照，以及用额外输入延迟限制重演量的设置。下例演示其中的分位数取舍；公式是本文自定，不是 Fusion 内部算法。
官方对应配置：Max Late Snapshots、Redundant Snapshots、Client Max Resims Per Frame，均注明 Fusion 2.1。Time Synchronization。本例的额外间隔是独立可加的教学余量，不能当作官方 Redundant Snapshots 的精确公式；尾部比例也不是实际卡顿率。
Quantum 将玩法放进自己的 ECS 和确定性数学、物理等库，Unity 负责呈现。常规同步的核心是输入；服务端协调输入与时钟，客户端运行模拟。这种结构省去了持续发送所有对象状态的需求，但要求玩法遵循确定性规则。需要权威玩法复核时，不能把协调输入的服务端自动视为完整裁判模拟。官方架构。
Verified 帧使用服务器确认的输入，Predicted 帧允许客户端提前运行。Quantum 文档描述了持续回滚/重演的工作方式，不能简单理解成“只要位置误差超阈值才重算”。Frames。输入延迟范围与回滚历史窗口可配置。SessionConfig。
其 Prediction Culling 还能跳过不相关对象的预测计算，而在 verified 帧维持必需的完整模拟。这与 AOI 不同：一个减少重算 CPU，另一个减少向某客户端发送的数据。官方裁剪说明。
本地自主角色把移动写入 FSavedMove_Character，发送移动数据；服务器重新执行并确认或纠正；客户端据此删除确认记录、重放剩余移动。其他机器上的角色走网络平滑。扩展冲刺、攀爬等移动时，影响模拟的额外数据也要保存、序列化和重放。官方 CharacterMovement 流程。
所以：使用 CharacterMovement 获得的是角色移动的预测机制；不能据此推断通用 Actor 复制也会重放全部逻辑，或 LineTrace 自动访问过去的命中盒。需要哪类历史，仍要选对组件或另行实现。
根据服务器与本地速度调整运动，使对象逐渐接近应在的位置。UE Predictive Interpolation 属于这一路线。它允许一些本地预测交互，成本通常比完整重算低，但碰撞和高延迟仍会降低质量。
保存每个物理 tick 的状态；按相同历史帧比较服务器结果，差异足够大时恢复、纠正、重算到当前。UE Network Physics 提供相关底层机制，需要 C++ 接入输入和自定义状态；消耗历史内存与重算 CPU。
Epic Networked Physics Overview。两种模式可以混用；“Predictive Interpolation”是特定物理模式名，不能直接等同于前文两快照之间的普通位置插值。
Fusion Unity 物理重演也要求框架接管物理步进，并把逻辑放进网络 tick。高延迟客户端需要重复做更多物理工作，应在目标最坏网络下测 CPU。Fusion Physics Addon 2.1。
IInputComponentData 表达带 tick 的输入；预测逻辑进入 PredictedSimulationSystemGroup，一帧显示期间可能执行多个模拟 tick。Ghost 可以选择预测或插值，NetworkTime 暴露模拟与插值时间。
一个细节很能体现框架价值：部分快照可能让不同对象处于不同确认时刻。代码必须尊重 Simulate 标记，只重算该 tick 真正需要更新的实体，否则会把部分对象多推进。一次性特效也要防止重复触发。官方预测循环与部分快照。
框架还提供预测平滑和逐对象切换预测模式。它改变的是客户端需要模拟的范围和时间，不是让所有 MonoBehaviour 自动确定性执行。1.10 功能入口。
AnticipatedNetworkVariable 与 AnticipatedNetworkTransform 分开保存预期值和权威值。你先让玩家看到结果，再根据服务器数据决定忽略旧响应、重新预期或平滑纠正。
它适合解释“点击后立即变色，随后确认”的交互。官方仍明确说明它没有完整的 rollback-and-replay 预测循环。回调能让开发者继续搭建系统，不等于已经替你记录并重放了全部移动输入。不能只因为产品叫 Netcode，就推断 NGO 与 Entities 的预测覆盖相同。NGO 2.13 Client anticipation。
UE Replication Graph 把相关对象组织成可复用的节点/列表，避免每个 Actor 每次逐一检查每个连接。官方用 Fortnite 的规模说明为何朴素检查会成为 CPU 瓶颈；这不是“所有对象每 tick 都广播”的方案。Replication Graph。
Iris 的优先级会跨网络 tick 累积，发送后重置，让低优先对象也有机会更新。这与 Gaffer 的优先级累积思想相近；过滤决定接收者，优先级决定发送顺序。当前相关文档带有 Experimental 提示，不能据此统一称作所有项目默认的成熟配置。Iris Prioritization。Iris 和 Replication Graph 是替代系统，不能假设同时叠加启用。迁移边界。
工程推导：增量数据应说明依赖哪份基线；基线没收到就需要恢复路径。输入可冗余带上最近几步，用序号去重。这通常比把所有高频状态排进可靠队列更能保持新鲜度，但不能消除突发丢包。
SDK 下载页提供 3.0.0 Preview，发布日期 2026-07-17，要求 Godot 4.6+，以 GDExtension 接入。官方明确说开发预览不用于生产，API 可能变化。不能再简单说“Photon 只有 Unity 集成”，也不能因此把成熟 Unity 版的所有特性都算给 Godot。官方 SDK 状态。
Client-Server 模式使用 FusionServerReplicator：queue_input() 入队，process_input_queue() 驱动同一份输入处理；本地预测、服务端权威执行。预测重置后重新执行缓冲输入，is_new 用来避免重复播放效果，state_reset 通知纠正。Prediction and Input。
Shared 模式是对象拥有者直接写状态；Client-Server 才是输入与权威模拟的路线。两种模式不能只看“谁更快”就替换，改模式会改变权限与代码结构。拓扑对照。本次未验证 Godot 版具备 Unity LagCompensation Hitbox/sub-tick 的同等历史查询 API，也没有安装、运行其 SDK。
原生 MultiplayerSynchronizer 管属性复制和可见性；你的预测控制器仍需负责输入确认、历史和校正。社区 netfox 已有 NetworkRollback / RollbackSynchronizer、输入延迟、输入冗余、显示偏移、历史上限与差异状态。其文档还描述了服务器接收旧输入后回算的行为，所以不能默认它和“服务器永不回滚”的设计完全相同。netfox 回滚指南。
刚体是额外的工程门槛。netfox 物理指南要求可手动步进的物理实现，并列出带步进能力的引擎构建或替代物理插件，配合 PhysicsDriver、NetworkRigidBody 和保存的物理状态。不要把“节点坐标能回滚”误认为整个物理世界已恢复。这里是该插件文档的条件，本次未测试你项目的引擎与插件组合。物理接入要求。
如果继续做 Godot 实时动作游戏：先验证一个权威角色的“输入 → 本地预测 → 服务器确认 → 重演”，再加入远端快照插值；射线武器另做历史命中盒。对比原生自建、netfox 与 Fusion Godot 预览时，用同一段输入和同一组网络扰动测纠正、CPU 和快照年龄，别只比较能否看到两个人移动。
这也解释了研究与产品的关系：经典方法已经被封装进框架；近期工作的价值常在预测模型、适应策略、计算预算或保证边界。本文核对的商业文档不能证明 MPAI-SPG、CLAAP 或该 OPODIS 模型已经被这些 SDK 集成。
框架资料核对日期：2026-09-10。版本、来源与未验证项清单。商业服务身份、开源许可、SDK 功能和生产成熟度是不同维度；本文没有评估价格、许可合同或吞吐量承诺。