UE5 Iris 复制系统
Iris 是 UE5.4+ 的新一代复制系统，冲着「默认复制栈在大规模下的 CPU 瓶颈」来的。它还不是默认、多数项目没用，所以本篇定位是选型篇：讲清它是什么、解决什么、代价多大、你该不该上——而不是实现级细节。
一句话结论
Iris 把「每连接轮询每 Actor」换成「全局脏状态追踪 + 每连接过滤」，为大规模复制降 CPU；但 UE5.4+ 才可选、非默认、迁移有成本。
版本与状态
Iris 是 UE5.4+ 引入的可选实验/预览特性，默认关闭，需显式启用并改造代码。UE4 与早期 UE5 完全没有。生产项目采用前务必确认目标引擎版本的成熟度。
场景问题
打个比方：默认复制栈像每个订户派一个专属编辑。100 个订户，每个编辑都把全部 1000 篇稿子从头看一遍、挑出「跟我这位订户有关且有改动的」——同一篇稿子被 100 个编辑各读了一遍，纯重复劳动。
Iris 换成「中央审稿 + 分发过滤」：先由一个中央编辑部把全部稿件过一遍，标出「哪些改了」（全局脏状态，只算一次），再按订户名单分发（Filtering）。改动只判定一次，订户数涨到 200 也不会让审稿工作翻倍。
和 ReplicationGraph 的差别：RepGraph 是给编辑们发了一张片区地图——不用翻全部稿子，只翻自己片区的，但每个编辑还是各翻一遍。Iris 是直接改掉「每人各翻一遍」这件事本身。所以两者职责重叠、不会同时上。
Relevancy 与带宽预算 讲过：默认复制栈的判定是 O(连接×Actor)，大房间下 CPU 是真瓶颈。ReplicationGraph 用空间网格缓解了「相关性判定」，但属性差分比较（每连接对每 Actor 遍历属性）仍是重活。Iris 想更彻底地重构这条路径。面试里被问「听说过 Iris 吗」，能讲清「它解决的是默认栈的哪个瓶颈、和 ReplicationGraph 什么关系」就够了。
实现方案
1. 范式变化：从「每连接轮询」到「全局脏 + 每连接过滤」
| 默认栈 | Iris | |
|---|---|---|
| 脏状态发现 | 每连接 × 每 Actor 遍历属性比较（或 Push Model 标脏） | 全局一次追踪脏状态，所有连接共享 |
| 相关性 | 每连接判定 | 集中的 Filtering 系统 |
| 序列化 | 每连接各自序列化 | 尽量复用、批量化 |
| 数据模型 | Actor/属性 分散 | NetObject + Protocol 描述统一 |
核心思路：脏状态只算一次（不是每连接算一次），然后按连接做过滤和发送。这把「随连接数线性放大的重复工作」收敛掉。
2. 核心概念
ReplicationSystem：Iris 的中枢，取代UNetDriver里那套复制逻辑（底层收发的 NetConnection/Socket 仍在，见 NetDriver/Channel/Bunch）。NetObject：被复制对象在 Iris 里的统一表示，携带一份序列化Protocol（描述有哪些可复制状态、怎么读写）。Protocol：由反射 + 声明生成的复制协议描述，是「怎么序列化这个对象」的元数据。NetRefHandle：对象的网络引用句柄，跨端稳定标识一个 NetObject。
3. Filtering / Prioritization / Group
- Filtering：集中的相关性过滤（谁收谁），对应默认栈的 Relevancy + ReplicationGraph 职责。
- Prioritization：带宽不足时谁先发，对应
NetPriority。 - Group：把对象分组批量管理相关性/优先级，类似 ReplicationGraph 节点的思想但更系统化。
与 ReplicationGraph 的关系：两者职责高度重叠——都想解决大规模相关性/优先级。Iris 是更彻底的重写，长期看是 ReplicationGraph 的继任者；但现阶段 ReplicationGraph 成熟、Iris 新。同一项目不会两者都上。
4. 迁移代价
NetSerialize改造：自定义序列化的 struct 需适配 Iris 的序列化模型。- API 不兼容：部分复制相关 API 变化，现有复制代码要改。
- 插件/第三方适配：依赖默认复制栈的插件（含部分 GAS 路径）需确认是否支持 Iris。
- 团队学习成本：一套新心智模型。
5. 三选一：默认栈 / ReplicationGraph / Iris
| 方案 | 何时选 | 代价 |
|---|---|---|
| 默认复制栈 | 连接数不大（几十人内）、常规项目 | 无额外代价，够用 |
| ReplicationGraph | 明确要做大房间（100+），当前引擎版本，团队熟悉 | 写自定义 Graph 类，把 Actor 分类到节点 |
| Iris | UE5.4+ 且愿意吃新特性、超大规模、长期项目 | 迁移改造 + 新心智模型 + 成熟度风险 |
判据一句话：够用就默认；要大房间且求稳用 ReplicationGraph；押注未来且能承担迁移成本再考虑 Iris。绝大多数在产项目现在仍是「默认栈 + 必要时 ReplicationGraph」。
为什么这么做
脏状态只算一次：默认栈最大的浪费是「同一个属性变化，对 N 个连接各比较一次」。连接越多重复越多。Iris 把脏状态发现全局化，让这部分工作与连接数解耦——这是它能扩展的根本。
统一数据模型（NetObject/Protocol）：默认栈的复制逻辑散落在 Actor/Channel/RepLayout 各处，难优化难批量。Iris 用统一的 NetObject + Protocol 描述，才能做批量序列化、SIMD 友好的内存布局等系统级优化。
为什么别的选择不行
- 继续堆 ReplicationGraph：它优化了相关性判定，但没动「每连接属性差分/序列化」这块；超大规模下这块仍是瓶颈。Iris 才动了它。
- 现在就全项目切 Iris：预览期成熟度、插件兼容性、迁移成本都是风险；多数项目收益还不足以抵消。选型要看规模是否真的到了默认栈扛不住的地步。
- 不了解就上：Iris 改的是复制核心，盲目启用可能踩兼容坑（GAS、第三方插件）。先评估目标版本状态。
沉淀结论
Iris = UE5.4+ 可选新复制栈，把「每连接轮询每 Actor」换成「全局脏状态 + 每连接过滤」，用 ReplicationSystem/NetObject/Protocol/NetRefHandle 统一数据模型，为超大规模降 CPU。与 ReplicationGraph 职责重叠、是其继任方向。迁移有成本（NetSerialize/API/插件）。选型：够用默认栈、求稳大房间用 ReplicationGraph、押未来超大规模再上 Iris。
记忆口诀
定位：UE5.4+ / 可选非默认 / 冲大规模 CPU 瓶颈
范式：全局脏状态算一次 / 每连接过滤 / 与连接数解耦
概念：ReplicationSystem 中枢 / NetObject+Protocol 统一模型 / NetRefHandle 句柄
vs RepGraph：职责重叠 / Iris 更彻底 / 继任方向 / 不同时上
选型：够用默认 / 大房间求稳 RepGraph / 押未来超大规模 Iris
内容来源
综合整理。主要参考：Epic 官方文档 Iris Replication System（UE5.4+ 文档）、Epic 官方技术分享。因 Iris 处于演进中，具体 API 以目标引擎版本官方文档为准；本篇聚焦范式与选型，不承诺实现级细节。
相关专题：默认栈的 O(连接×Actor) 瓶颈与 ReplicationGraph 见 Relevancy 与带宽预算；默认属性差分/Push Model 见 属性复制；底层收发（Iris 不改这层）见 NetDriver/Channel/Bunch。
自测：合上资料能说清楚吗？
Iris 相比默认复制栈的核心范式变化是什么？
参考答案
从「每连接轮询每 Actor 做属性差分」变为「全局脏状态追踪算一次 + 每连接过滤发送」。默认栈最大的浪费是同一属性变化对 N 个连接各比较一次，重复随连接数放大；Iris 把脏状态发现全局化，与连接数解耦，从而在超大规模下降 CPU。
Iris 和 ReplicationGraph 什么关系？会同时用吗？
参考答案
职责高度重叠——都解决大规模的相关性/优先级问题。Iris 是更彻底的重写（还动了属性差分/序列化这块，RepGraph 没动），长期看是 ReplicationGraph 的继任方向。同一项目不会两者都上：现阶段成熟项目用 RepGraph，押注未来的超大规模项目才考虑 Iris。
一个 100 人项目，该选默认栈、ReplicationGraph 还是 Iris？
参考答案
优先 ReplicationGraph（当前成熟、专为大房间、能有效破 O(连接×Actor) 判定瓶颈）。默认栈在 100 人下判定 CPU 大概率扛不住。Iris 只在 UE5.4+ 且团队愿意承担迁移成本、成熟度风险、追求长期超大规模时才考虑。判据：够用默认、大房间求稳 RepGraph、押未来 Iris。