Cook 与 DDC 基础设施
自动关联目录：Cook 与 DDC 基础设施
技术细节见 Cook 与打包流程；本篇只讲团队级基础设施，不重复 Cook 的步骤与技术原理。
1. 定位
DDC（Derived Data Cache）命中率决定团队的迭代速度：命中就秒开，不命中就要重新生成（着色器编译、纹理压缩、Nanite 构建、距离场……），一次全量可能是几十分钟到几小时。
一句话定位：共享 DDC 是 UE 团队协作里投入产出比最高的一项基础设施。
2. 三层缓存
| 层 | 位置 | 特点 |
|---|---|---|
| Local DDC | 每台机器本地 | 只对自己有效 |
| Shared DDC | 网络共享目录 | 团队共享（关键） |
| Cloud DDC | 云端 | 分布式/远程团队 |
只配 Local DDC 的后果：新人拉完工程第一次打开，要自己把整个项目重新生成一遍——这就是"新电脑卡一上午"的原因。
3. 什么会命中/失效
| 项 | 说明 |
|---|---|
| 缓存 key | 包含所有输入的哈希（含着色器源码） |
改 .usf | 自动失效并重编（见 材质与着色器编译） |
| 改纹理压缩设置 | 失效 |
| 改引擎版本 | 大面积失效 |
升级引擎版本会导致 DDC 大面积失效——这是升级时最大的隐性成本之一，要预留时间。
4. 基础设施建议
| 项 | 建议 |
|---|---|
| 必配 Shared DDC | 团队级网络共享 |
| 定期清理 | DDC 会无限增长，要有清理策略 |
| CI 机器也要接 | 让 CI 的产出回流到共享 DDC |
| 预热 | 重要版本前先跑一遍全量 Cook，把 DDC 填满 |
| 监控命中率 | 命中率下降说明配置有问题 |
"预热"是最实用的一招：发布或大版本前跑一次全量，让所有人（包括 CI）都能命中。
5. 与 Cook 的关系
| 项 | 说明 |
|---|---|
| Cook | 把资产转成平台可用格式（见 Cook 与打包流程） |
| DDC | 缓存 Cook 与编辑器生成的中间产物 |
| 增量 Cook | 依赖 DDC 与 Cooked 目录的缓存 |
| CI 上的 Cook | 应接共享 DDC，避免每次全量 |
6. 代价与权衡
| 设计 | 收益 | 代价 | 什么时候不该用 |
|---|---|---|---|
| Shared DDC | 迭代速度质变 | 需要存储与网络 | 单人项目可省 |
| Cloud DDC | 分布式团队 | 成本与延迟 | 同地团队用共享目录即可 |
| 预热 | 避免集体卡顿 | 占用 CI 时间 | 发布前值得 |
| DDC 无限增长 | — | 存储成本 | 必须定期清理 |
| 升级引擎 | — | DDC 大面积失效 | 升级要预留时间 |
7. 踩坑与排查
| 坑 | 现象 | 怎么验证 |
|---|---|---|
| 只有 Local DDC | 换机器就卡几小时 | 配 Shared DDC |
| DDC 路径配置不一致 | 命中率低 | 统一配置 |
| CI 没接共享 DDC | 每次全量 | 接上 |
| DDC 从不清理 | 磁盘爆 | 建清理策略 |
| 升级引擎没预留时间 | 集体卡住 | 升级前先预热 |
| 命中率不监控 | 问题发现晚 | 加监控 |
8. 排查顺序
1. 是否配了 Shared DDC？
2. CI 是否接入？
3. 命中率是否健康？
4. DDC 是否有清理策略？
5. 升级/大版本前是否预热？参考
- Cook 与打包流程 · 材质与着色器编译 · 构建农场与 CI
- World Partition（Builder Commandlets 让大世界不必整体加载）
许可协议：CC BY
作者：Davids
本文链接：https://hustjjd.github.io/b7edb5d9.html
更新于：2026年10月10日