Godot 原生、netfox 不能合并成一列。原生主要提供传输、RPC、属性复制与生成；netfox 在这些构件之上增加共享时间、历史、预测与回滚。与商业方案的差别，应看具体算法和集成范围，而不是付费与免费。
核对：2026-09-11。核心表以 Fusion Unity 2 的 Host/Server 模式为商业参照，时间策略特别注明 2.1；它不是可直接装入 Godot 的版本。netfox 发布页当前指向 v1.35.3，详细机制引用维护者文档；latest 可能领先发行包。下文“未核实”等于本次证据不足，不等于无法实现。
负责把约定的数据送到对端。你定义时间与纠正协议。
提供可参与回滚的时间循环和节点工具。你声明完整状态、接入可重演玩法。
把更多模拟、时间与历史机制放进统一框架。你仍负责玩法合法性与预测边界。
| 技术问题 | Godot 原生 | Godot + netfox | Fusion Unity 2 Host/Server |
|---|---|---|---|
| 共同的 tick 与时钟 | 物理帧和复制间隔不是跨机器共享时钟；时钟偏移、tick 对齐需自建。 | NetworkTime 驱动网络 tick；同步器区分远端、参考、模拟时钟，模拟时钟单向推进。[N1] | 框架管理预测与插值时间轴；2.1 暴露自适应时间配置。[F1] |
| 按键立即移动 | 自己采集带编号输入、本地模拟、发送，并记录待确认历史。 | RollbackSynchronizer 声明 Input / State 属性；在 _rollback_tick 中执行可重演逻辑。[N2] | 在 FixedUpdateNetwork 中消费输入，参与框架预测；网络状态随权威快照恢复。[F2] |
| 权威更新来了怎么办 | 复制器写属性；“确认到哪条输入、恢复与重放”不是它的职责。 | 恢复历史状态，按回滚 tick 重算，再记录状态；遗漏的玩法变量仍会造成持续纠正。[N2] | 从权威状态重演后续 tick；开发者仍须让相关逻辑与状态参与重演。[F2] |
| 远端画面平滑 | 网络时间戳与快照缓冲需设计；引擎物理插值不等于网络抖动缓冲。 | StateSynchronizer 配合 TickInterpolator；后者插值网络 tick 之间的显示状态，可用 teleport 跳过突变。[N3] | 快照插值与框架时间管理结合；缓冲保证尽量有可插值的样本。[F1] |
| 坏网络时自动等多久 | 自行测到达间隔、决定分位数、欠载策略和时钟调整。 | 有 input_delay、display_offset、history_limit；本次未核实与 Fusion2.1 相同的分位数缓冲控制器。[N2] | 2.1 按抖动分布配置允许迟到比例和冗余快照，亦可用输入延迟限制重演量。[F1] |
| 输入包丢失 | 传输层可选可靠/不可靠；输入冗余、去重、执行确认需另建。 | input_redundancy 把历史输入随新输入再发，减轻丢包缺口；突发丢包仍会超出覆盖。[N2] | 输入与预测机制集成；具体冗余与恢复表现仍须按 SDK 配置实测，不能比较一个通用“成功率”。 |
| 射手所见的历史命中 | 需自建历史命中盒、合法射击时间、查询与最大回溯窗口。 | 有回滚历史不等于有射手时间视角的命中查询。未核实开箱即用的同等 Hitbox/sub-tick API；FAQ 也指出 favor-the-shooter 不容易。[N4] | HitboxRoot / Hitbox + LagCompensation 查询历史；可选 sub-tick；限 Host/Server。[F3] |
| 刚体碰撞后重演 | 完整物理状态保存、恢复及可控步进要单独解决；复制 transform 不足以恢复物理世界。 | 物理驱动与 NetworkRigidBody 可接入回滚；指南要求支持手动步进的引擎/物理插件，且要保存 physics_state。[N5] | Physics Addon 接管步进、恢复和重演；多次物理计算增加客户端 CPU。[F4] |
| 只向相关玩家发送 | MultiplayerSynchronizer 有 per-peer 可见性过滤；相关性规则由你写。[G1] | v1.35.3 有接收者过滤；StateSynchronizer 源码亦使用 PeerVisibilityFilter。兴趣范围与大世界调度仍要设计。[N6/N7] | 已有兴趣管理体系；要区分复制筛选与客户端预测范围，详见前章。 |
| 状态与带宽 | 有复制间隔、按变化同步等构件；紧凑编码和总带宽预算仍需设计。[G1] | StateSynchronizer v1.35.3 按每个接收者 ACK 的基线编码差异；基线缺失时退回完整状态。[N7] | 状态同步与网络模拟集成；节省多少字节取决于状态、频率和对象范围，不在此给无依据的倍率。 |
| 声音、伤害、掉落去重 | 自己设计事件编号、确认条件和补偿规则。 | 在回滚环境中区分模拟与副作用；latest 指南列出输入到达状态查询。is_fresh 与 input_delay 有适用警告。[N2] | 模拟可能重复执行，框架不能替你决定一次伤害何时不可撤销。 |
| “确定性”的要求 | 内置联网不保证跨平台逐位确定。 | 客户端—服务器的状态纠正路线不要求严格逐位相同，但差异必须可控；它不是只同步输入的严格确定性框架。[N4] | 依赖权威快照纠正预测；与 Quantum 的确定性输入同步应分开评价。 |
最重要的三个差别：“有插值”不代表有自适应抖动缓冲；“有回滚”不代表有历史射线命中补偿；“可以纠正状态”不代表所有端必须逐位确定。技术对比要拆到这一层。
按游戏协议决定丢弃、限制、后续执行或对特定动作查历史。客户端收到确认再校正自身预测。历史命中查询可以只处理碰撞盒，不重算全部玩法。
这是权威状态预测的一类架构，不代表所有框架的默认晚包策略都相同。
晚到输入可能触发服务器从相关历史 tick 重演，再将更新状态发给客户端。参与回滚的对象、保存的变量与允许窗口决定能重算什么。[N2]
不能把这个行为当作“只在客户端回滚”。服务器也要有 CPU 与不可撤销事件的预算。
实际后果：如果 tick 104 已经发放掉落，tick 102 的新输入又改变了死亡结果，就需要延后提交、事件去重或补偿机制。把伤害代码移进 _rollback_tick 只是开始；还要决定哪一刻死亡成为最终结果。类似问题在其他回滚架构也存在，解决方式取决于它们的确认与历史规则。
| 商业路线 | 相对 netfox 的核心差别 | 面向 Godot 的实际意义 |
|---|---|---|
| Fusion Unity 2/2.1 | 同属状态纠正型预测，但时钟控制、历史命中查询、Unity 物理接管形成更集中的接口体系。 | 适合作为协议与功能参照；Unity 的 FixedUpdateNetwork/Hitbox 不是 Godot 原生接口。 |
| Quantum 3 | 提供确定性模拟环境、确认/预测帧；常规输入分发驱动相同模拟。netfox 通过权威状态纠正来容忍有限分歧。[Q1/N4] | 不能只替换网络插件，保留全部 Godot 玩法和物理不变；这是模拟架构迁移。 |
| UE CharacterMovement / Network Physics | 角色 SavedMove 与物理历史/步进由不同引擎组件深入集成；netfox 则通过节点配置、回调和额外物理驱动接入。 | 学习保存哪些移动状态、何时重算很有价值；无法直接安装这些 UE 组件到 Godot。具体机制见 UE 和 网络物理。 |
| Unity Entities 1.10 | 预测集成进 ECS 系统组与逐实体 Simulate 标记；netfox 以节点/属性为组织单位。 | 差异在调度与数据布局，不意味着 ECS 必然更快；用同样对象与玩法测量才可比较。见 Entities。 |
| Unity NGO 2.13 | 有 anticipation 构件，但没有完整回滚重放循环；就这项技术而言，不能笼统认为商业引擎官方包比 netfox 更完整。 | 保留 Godot 并采用 netfox，可以获得 NGO 本身没有提供的回滚循环；不代表全部功能与质量都胜出。见 NGO。 |
| Fusion Godot 3 预览 | 同在 Godot：FusionServerReplicator 用输入队列、prediction reset 和 buffered input 重演；netfox 用 NetworkRollback 的历史 tick 循环。[FG1] | 直接可比，但 Fusion Godot 仍是预览；不能借 Unity 版名声认定其拥有同等命中补偿、物理重演或自适应缓冲。见 SDK 状态。 |
| 你在同步什么 | 合适的构件 | 需要自己保证 |
|---|---|---|
| 自己控制、需要立即响应的角色 | RollbackSynchronizer + 相关 Input/State 属性 | 所有影响结果的变量参与历史；移动、碰撞、随机数与技能状态可重演。 |
| 服务器单独驱动的 NPC 画面 | StateSynchronizer + TickInterpolator | NPC 是否需要与预测对象交互；若需要，不能只考虑显示平滑。 |
| 渲染模型、朝向 | TickInterpolator | 只插值应显示的属性；传送重生重置插值，不污染下一次模拟。[N3] |
| 无需回滚的少量配置/状态 | 可保留原生 MultiplayerSynchronizer | 同一属性只能有清晰的写入负责人，避免原生复制器与回滚控制器争抢。 |
| 刚体交互 | 物理驱动 + NetworkRigidBody + RollbackSynchronizer | 可控步进、physics_state、接触状态恢复；按驱动文档验证，不能只保存位置速度。[N5] |
源码核对后的修正：一份旧节点指南仍说 StateSynchronizer 没有 delta/visibility，但 v1.35.3 源码已经有两者。第 46 行创建 PeerVisibilityFilter；第 169–200 行按连接取已确认的 reference_tick，生成差异状态；基线不存在、历史已清理或差异编码没有收益时，退回完整状态。第 235–264 行处理差异状态及 ACK。固定版本源码。
例如 A 确认到 tick 100，B 确认到 tick 96：服务器生成 tick 105 更新时，对 A、B 可以使用不同基线。如果 B 的基线已从历史清理，就发送完整状态。这说明 netfox 已有具体的带宽恢复机制；它仍不等于自动提供空间索引、大规模兴趣调度与固定字节预算。
下面是建议的验收条件，不是本次测得的结果。以两人角色移动、推箱子和射线开火为同一场景；固定逻辑 tick、状态发送频率、输入记录和网络轨迹。分别测原生自建、netfox 与可运行的商业候选。
成本直觉：历史内存大致随“对象数 × 每对象保存状态 × 历史 tick 数”增长，实际还含容器与物理缓存；重算耗时随重演 tick 和参与对象增加。只同步输入可能省网络，却要求每端模拟更多世界。状态筛选可能省流量，却增加依赖与恢复设计。任何框架都不能免除这些交换。
针对 Godot 的建议：原生足够支撑你自建任何一种协议，但工程量最大；netfox 已补齐许多时间与回滚构件，值得优先验证角色与小范围交互；严格射手视角命中补偿、复杂刚体恢复和大型世界调度要另设验收。Fusion Godot 可作为预览对照，不应直接当成成熟 Unity 版的替代品。
[G1] Godot MultiplayerSynchronizer；原生能力缺口指该组件未提供对应机制，不指引擎无法扩展。
[N1] NetworkTimeSynchronizer。[N2] NetworkRollback。[N3] TickInterpolator。[N4] netfox FAQ。[N5] Physics。[N6] v1.35.3 发行说明。[N7] v1.35.3 StateSynchronizer 源码（本地研究副本）。
[F1] Fusion 时间同步。[F2] 模拟循环。[F3] 命中补偿。[F4] Physics Addon。[Q1] Quantum Frames。[FG1] Fusion Godot 输入与预测。
这里只核实公开技术机制，没有宣称安装测试了这些 SDK，也没有用一个包的文档代替另一个版本。没有可比压测数据，所以不列延迟、并发量或 CPU 的“获胜排名”。