自动关联目录：UE 版本要点

覆盖说明：官方 5.8 文档站为本库的对照基准。版本间的具体差异以官方 Release Notes 与实测为准，本篇只给"升级评估该看什么"的框架，不硬编造变更清单。

1. 定位

"要不要升引擎版本"是个工程决策，不是技术偏好：它的成本不在下载，而在回归验证、DDC 失效、以及第三方插件适配。

一句话定位：升级的真实成本 = 回归测试 + DDC 重建 + 插件适配 + 团队适应，其中第二项最容易被忽略。

2. 本库的版本基准

项	说明
文档对照基准	UE 5.8（官方 `unreal-engine-5-8-documentation`）
本库各篇的依据	抓自 5.8 官方文档；涉及版本差异处均标注"以目标版本为准"
已知有版本差异的项	半透明的 OIT 选项、动画压缩方案、部分 CVar 名

各篇里凡是我无法从官方核实具体数值/选项名的，都标了"以目标版本为准"，不要直接照抄。

3. 升级评估框架

维度	要看什么
新特性	是否解决了当前痛点（如某渲染特性、某工作流）
破坏性变更	API 改名/移除、行为变化、默认值变化
DDC 失效	升级会导致大面积失效，要预留时间（见 Cook 与 DDC 基础设施）
第三方插件	插件是否支持新版本
平台与工具链	SDK 版本、编译器要求
回归面	现有功能需要重测多少

4. 版本演进的主线（大致方向）

方向	说明
Nanite / Lumen / VSM	逐版本扩展支持范围与优化（见对应各篇的"平台限制"）
World Partition	逐步成为大世界默认方案（见 World Partition）
渲染特性弃用	官方已把光追 GI / 光追反射 / 光追半透明标记为弃用（见后处理与体积）
输入系统	从旧输入迁移到 Enhanced Input（见输入映射与触发）
脚本与工具	Python、Editor Utility 等扩展能力
移动端	各版本支持范围不同（见移动平台与图形 API）

一条值得记住的趋势：官方在把一些旧方案标记为 deprecated（如光追 GI/反射/半透明）。新项目不该再基于它们设计——这是升级评估时的一个硬信号。

5. 升级的执行顺序（建议）

1. 读目标版本的 Release Notes（重点：破坏性变更）
2. 在分支上做升级，不要直接在主干
3. 编译并修 API 变更
4. 预热 DDC（跑一次全量，避免团队集体卡）
5. 回归测试：渲染表现 / 网络 / 打包 / 目标平台
6. 性能基线对比（见性能方法论篇）
7. 确认第三方插件可用

6. 代价与权衡

设计	收益	代价	什么时候不该升
跟随新版本	新特性、已知问题修复	回归成本、DDC 失效	项目临近发布时绝不该升
停留在旧版本	稳定	错过修复与新特性	长期项目会越来越难升
跳版本升级	一次到位	风险叠加	建议逐步升
只升不测	快	上线才发现问题	从不做

7. 踩坑与排查

坑	现象	怎么验证
发布前升级	引入未知回归	发布窗口内禁止升级
忽略 DDC 失效	团队集体卡几小时	升级后先预热（见 DDC 篇）
第三方插件未适配	编译失败/运行时崩	升级前先确认插件支持
默认值变化未察觉	画面/行为变了但代码没改	对比 Release Notes 的默认值变更
用了 deprecated 特性	未来版本可能移除	检查是否用了光追 GI/反射/半透明等
只编译不测	运行时才出问题	完整回归

8. 排查顺序

1. 升级前：读破坏性变更 + 确认插件支持
2. 升级中：分支上进行，修 API
3. 升级后：预热 DDC → 回归测试 → 性能基线对比
4. 长期：关注 deprecated 标记，别在新项目里用将弃用的方案

参考

Cook 与 DDC 基础设施（升级的隐性成本）
性能方法论（基线对比） · 后处理与体积（已弃用特性）
World Partition · 移动平台与图形 API · 输入映射与触发
官方 Release Notes（升级前必读）