做 UE 角色动画蓝图做得多了你会发现一个特别扎心的现象角色动得越丰富AnimGraph 里的节点连线越像蜘蛛网跑起来也越肉。明明只是加了一个瞄准叠加、一个换弹蒙太奇、一个上下半身混合帧率就能掉下去一截。这个问题的核心往往不在美术资源而在于同一个状态机输出在动画蓝图里被引用了好几遍每一遍都在重复计算。今天要聊的就是专门用来解决这类重复计算的“缓存姿势”Cache Pose节点以及我拿它实战优化一个角色蓝图的全过程。这篇内容更适合两种人正在跟动画蓝图性能较劲的 UE 开发者以及刚学会状态机、想搞清楚下一步怎么优化性能的新手。1. 先从性能账算起为什么“复用”不等于“免费”1.1 动画蓝图里那条“看似共享”的连线很多人在 AnimGraph 里接线都很随意一个状态机输出引脚拖三根线出去分别接到瞄准叠加、蹲伏混合、蒙太奇插槽。看起来是一个输出被三处复用心里想的是“同一个姿势我只算一次剩下的都是引用应该不贵吧”。但在引擎的实际评估流程里路径并没有那么简单。动画蓝图虽然是一个有向图很多节点也需要按序评估但如果一个节点的输出被多个下游节点需要而这个节点本身又没有做缓存那下游每个节点在求值时都可能触发上游链路重新计算一次。换句话说你看到的一条线在每一帧可能被走了好几遍。我当时在一个模拟项目的角色蓝图里移动状态机输出被接了三个地方打开性能分析一看这个状态机每帧被求值了三次每次内部还要处理两三个状态的混合、过渡条件、曲线更新。三次加起来比整个 AnimGraph 其他所有节点还贵。这其实属于很典型的“复用陷阱”连线复用只是拓扑层面的复用不是计算层面的复用。1.2 缓存姿势解决什么问题缓存姿势节点Cache Pose就是为这种场景准备的。它的工作方式很直接节点把自己的输入姿势在第一次被求值时存成一份快照同一帧内后续再有别的节点引用它直接读取快照不再往上游跑。这样移动状态机每帧只需要真正求值一次后面接三个、四个消费者都只拿快照。打个不太严谨的比方状态机是厨房Output 是刚出锅的菜。你以为把同一道菜的菜谱发给三个客人就能一次做好三份实际上如果没有缓存厨房会按照菜谱重新炒三遍。Cache Pose 相当于提前把菜盛好放在保温柜里谁要就直接端不用再开火。当然它缓存的是“整个姿势”不是某个骨骼或某个混合的局部结果。所以使用场景很明确当同一个子图的输出要被多个下游节点引用而这个子图本身的求值成本又不低时用 Cache Pose 包住它最合适。2. Cache Pose 节点入门位置、用法与命名2.1 在哪找节点怎么连如果你还没用过这个节点操作步骤其实很少打开动画蓝图 AnimGraph。在节点搜索框输入“Cache Pose”拖入图中。把它连到需要复用的姿势链路上。一般来说是放在某个状态机输出之后、后续分支开始之前。选中节点在细节面板中重命名。我习惯用“CachePose_”做前缀比如 CachePose_BaseMove。把原本从状态机输出接出去的线全部改接到这个 Cache Pose 的输出引脚上。这里有个容易被忽略的点Cache Pose 不是一个“自动替换所有引用”的开关它只是一个需要手动接入的节点。你必须在接入后手动把下游节点的输入引脚重新连接否则原来的连线还指向旧节点缓存没有覆盖到。2.2 Cache Bone 与 Cache Pose 的分工很多教程会把 Cache Bone 和 Cache Pose 一起提但两者的粒度完全不同。Cache Pose 缓存的是整个姿势结果适合缓存状态机输出这种大块头Cache Bone 缓存的是骨骼空间里的某个骨骼变换通常用在多个 IK 节点、多个后处理节点都要读取同一块骨骼数据时。实际项目里两者可以组合用Cache Pose 缓存基础移动Cache Bone 缓存手部骨骼再分给不同 IK 求解器。需要记住的是二者都是“同一帧内的复用”不是跨帧缓存。2.3 为什么命名和注释不是小事我在真实项目里踩过一个很浪费时间的坑优化完的动画蓝图里放了三个 Cache Pose名字全是默认的“CachePose”没人知道哪个缓存的是基础移动哪个缓存的是瞄准姿势。结果 UI 调到一半找错了节点改了缓存内容角色动画变得莫名其妙。从那以后我给自己定了两条规矩第一所有缓存节点必须用业务语义命名比如 CachePose_BaseMove / CachePose_AimPose第二在 AnimGraph 里用注释框把缓存区框起来写上类似“CACHE基础移动只计算一次”的说明。这样过几个月再回来维护哪怕只看了注释框也能立刻恢复上下文。3. 实战用缓存姿势改造一个角色蓝图3.1 优化前找出重复开销拿我当时处理的模拟项目举例。角色有地面移动状态机包含站立、走路、跑步三个状态每个状态里都做了上下半身混合角色肩膀上还有一把武器需要瞄准叠加另外有换弹动画和蹲伏覆盖。原始 AnimGraph 的接法很常见移动状态机输出同时被三个节点引用分别是 Layered Blend Per Bone、Blend by Bool、Slot 蒙太奇插槽。优化前我先做了一次性能定位。使用的工具是 Unreal Insights进入 PIE 模式打开 Insights勾选动画相关 channel让角色循环播放一段包含走路、跑步、瞄准、蹲伏的动作抓帧后进入 Animation Insights查看 AnimGraph 总耗时和节点耗时分布。结果很清楚AnimGraph 每帧总耗时 2.6ms 左右其中移动状态机相关的重复求值占了很大比重。这个数据一出来改方案就变得顺理成章给状态机输出加缓存。3.2 确定缓存位置确定缓存位置的原则是缓存放在被多个消费者共享的“公共上游”之后。对当前蓝图公共上游是移动状态机消费者是三个下游节点所以缓存尽量贴近状态机输出但不要包到状态机内部。改完之后节点逻辑变成这样StateMachine_BaseMove - CachePose_BaseMove - LayeredBlendPerBone上半身瞄准叠加 - BlendByBool蹲伏/站立切换 - SlotNode换弹等蒙太奇文字描述一下移动状态机每帧只求值一次输出写入 Cache Pose后面三个分支分别读取这份快照。Layered Blend Per Bone 用 CachePose_BaseMove 作为基础姿势再叠加上半身瞄准Blend by Bool 根据动画蓝图里的 bool 变量决定输出蹲伏还是默认跑动姿势Slot 节点则负责播放换弹这类蒙太奇。3.3 改造后的接线方法先看 Layered Blend Per Bone。把这个节点拖进 AnimGraph 后需要指定分支骨骼比如手臂骨骼然后设置叠加姿势的来源。这里把 Local Pose 输入接到 CachePose_BaseMove叠加姿势接瞄准相关的姿势序列或 AimOffset。这样每次手臂被叠加时拿到的底座是这份缓存快照而不是让状态机再算一次。再看 Blend by Bool。它是根据条件二选一的节点布尔输入可以接动画蓝图的变量比如 bIsCrouching。True 分支放蹲伏动画False 分支放 CachePose_BaseMove。使用缓存后当角色蹲下再站起来基础移动状态机不会被重复跑只有选择结果在变化。最后是 Slot 节点。Slot 节点的作用是播放动画蒙太奇比如换弹、挥手。把 Slot 的输入接到 CachePose_BaseMove蒙太奇播放时会临时覆盖基础姿势蒙太奇结束又回到缓存的移动姿势。这里顺序上我一般把 Slot 放在 Layered Blend 和 Blend by Bool 之后也就是到输出姿势的最后一步避免蒙太奇播放时被后续混合节点再叠一层。改完之后的实测数据本机场景仅供参考指标优化前优化后AnimGraph 每帧耗时2.6ms1.1ms移动状态机求值次数/帧3 次1 次游戏线程帧率85fps102fps3.4 一个容易踩的坑缓存层级不对有一个很常见的错误做法是把 Cache Pose 直接塞进状态机内部比如在走路、跑步每个状态里都放一个 Cache Pose。这会让状态机内部的混合和时间采样变得混乱尤其是过渡动画播放时不同状态可能各自保留自己的缓存快照结果看起来像角色“卡顿”或“瞬移”。正确做法是把缓存放在状态机输出之后状态机内部的逻辑保持原样让它正常处理状态切换输出的结果由缓存统一接管。4. 常见问题与排查技巧实录4.1 加了缓存后动画“定住”了这是初学者最容易遇到的。现象是某个动态效果比如换弹蒙太奇、面部表情变化加了 Cache Pose 后不再播放像被冻结在某一段。排查思路很简单看看这个动态分支在拓扑上是不是被缓存包住了。如果 Slot 节点本身位于 Cache Pose 的上游或内部那么缓存快照里记录的只是第一帧求值结果后续动态播放当然不会更新。解决方式是把 Slot 等重要动态节点移到缓存外部用 Cache Pose 只保存静态底座。4.2 加了缓存后反而更卡我也遇到过反向效果。原因通常有两个第一被缓存的子图本身太简单求值成本很低但 Cache Pose 节点本身也要维护缓存得不偿失第二被缓存的子图包含大量动态骨骼修改、物理模拟、IK 求解这些内容即使在缓存内也仍然需要每帧更新缓存并没有减少实际开销反而增加了额外管理。判断方法仍是用 Profiler如果加了缓存后节点调用次数没有明显下降或者 Animation 总耗时没有下降就说明缓存位置不对或粒度不对。4.3 状态机过渡表现异常表现是角色从走路切到跑步时过渡动画出现“迟滞”或“不连续”。排查后一般会发现问题不在 Cache Pose 本身而是把它放得过于靠近状态机内部干扰了过渡时间的采样。状态机内部有自己的一套时间推进和混合机制缓存不应该打断这个过程。安全做法是把它放在状态机输出端并且不要在过渡相关链路上共用两个不同的缓存名。4.4 版本和调试工具差异Cache Pose 在 UE4.26 到 UE5 系列里行为一致性还不错。调试时我推荐优先用 Unreal Insights 的动画通道比控制台命令更直观。控制台命令也可以配合用stat anim观察动画系统整体耗时stat unit看游戏线程、渲染线程、GPU 的帧耗时。需要提醒一点在 Debug 状态下动画蓝图可能走不到最优路径数据会比运行版本偏高所以对比优化效果时要用同一套场景和同一套配置否则很容易误判。4.5 常见问题速查表现象可能原因排查建议解决方案动态动画被冻结Slot/动态混合被包进缓存内部检查拓扑关系把动态节点移到缓存外性能没有下降缓存粒度不对或子图太简单抓帧对比调用次数取消缓存或调整边界过渡动画异常缓存放在状态机内部查看状态机内部连接移到状态机输出之后找不到对应缓存节点命名不清晰检查细节面板统一命名加注释框5. 从缓存姿势到动画蓝图整体性能调优5.1 Cache Pose 和 Cache Bone 组合使用在比较复杂的人形角色里上下半身往往有不同的逻辑。比如角色持枪瞄准时上半身要做瞄准叠加下半身要保留移动状态。这种情况下移动状态机的输出用 Cache Pose 缓存一份同一帧里如果上半身多个节点都要读取手臂骨骼变换再配合 Cache Bone 缓存手臂骨骼。这样整条主链路只求值一次骨骼缓存又减少了 IK 和多路后处理之间的重复读取。两者不是替代关系而是配合关系。5.2 一帧内缓存与跨帧更新的界限需要反复强调的是Cache Pose 缓存的生命周期只有一帧。它解决的是“同一帧里多处引用导致重复求值”的问题不是“让某个姿势在后续帧里都保持不变”的问题。如果你希望角色在远处降低动画更新频率那是另一套机制比如骨骼网格体的更新策略或 LOD。不要把两者混在一起理解。我之前见过有人试图用 Cache Pose 做跨帧帧率优化结果角色动作变得断断续续这就是用错了工具。5.3 什么时候不值得用 Cache Pose不是所有 AnimGraph 都需要加缓存。如果某个子图只有一个下游消费者或者子图本身是单个 Pose 节点加上 Cache Pose 基本没有收益反而增加节点数。更好的做法是先跑一遍 Profiler找到引用次数高、耗时占比大的子图再有针对性地加缓存。我在实际优化中通常先保留一张原始的拓扑截图然后每加一个缓存节点就在性能数据里做一次前后对比。这样做几次之后就能积累出比较清晰的使用直觉。最后分享几个偏个人的体会。第一次用 Cache Pose 时我图省事把一个 Slot 所在的整段链路都包进了缓存结果所有蒙太奇都不播了排查了将近两个小时才发现是拓扑位置的问题。后来我习惯在动手之前先画一张简单的数据流图把“哪个姿势需要复用、哪些节点必须动态更新”标清楚再进 AnimGraph 接线。另一个比较实用的习惯是给所有缓存节点统一加“CachePose_”前缀并把它们放在同一个注释框里注释框里写上“此区域只计算一次改动需谨慎”。这套做法不仅让自己少踩坑也方便后来接手的同事一上来就能看懂整张图。如果你现在正好被动画蓝图性能问题卡住建议不要急着删节点或优化美术资源先抓一帧性能数据看看是不是同一个状态机在反复求值。很多时候一个 Cache Pose 放在正确的位置就够用了。 
长河君 · 2026/10/23 5:50:10 · 阅读 1.2k UE动画蓝图性能优化：Cache Pose缓存姿势节点实战指南
做 UE 角色动画蓝图做得多了你会发现一个特别扎心的现象角色动得越丰富AnimGraph 里的节点连线越像蜘蛛网跑起来也越肉。明明只是加了一个瞄准叠加、一个换弹蒙太奇、一个上下半身混合帧率就能掉下去一截。这个问题的核心往往不在美术资源而在于同一个状态机输出在动画蓝图里被引用了好几遍每一遍都在重复计算。今天要聊的就是专门用来解决这类重复计算的“缓存姿势”Cache Pose节点以及我拿它实战优化一个角色蓝图的全过程。这篇内容更适合两种人正在跟动画蓝图性能较劲的 UE 开发者以及刚学会状态机、想搞清楚下一步怎么优化性能的新手。1. 先从性能账算起为什么“复用”不等于“免费”1.1 动画蓝图里那条“看似共享”的连线很多人在 AnimGraph 里接线都很随意一个状态机输出引脚拖三根线出去分别接到瞄准叠加、蹲伏混合、蒙太奇插槽。看起来是一个输出被三处复用心里想的是“同一个姿势我只算一次剩下的都是引用应该不贵吧”。但在引擎的实际评估流程里路径并没有那么简单。动画蓝图虽然是一个有向图很多节点也需要按序评估但如果一个节点的输出被多个下游节点需要而这个节点本身又没有做缓存那下游每个节点在求值时都可能触发上游链路重新计算一次。换句话说你看到的一条线在每一帧可能被走了好几遍。我当时在一个模拟项目的角色蓝图里移动状态机输出被接了三个地方打开性能分析一看这个状态机每帧被求值了三次每次内部还要处理两三个状态的混合、过渡条件、曲线更新。三次加起来比整个 AnimGraph 其他所有节点还贵。这其实属于很典型的“复用陷阱”连线复用只是拓扑层面的复用不是计算层面的复用。1.2 缓存姿势解决什么问题缓存姿势节点Cache Pose就是为这种场景准备的。它的工作方式很直接节点把自己的输入姿势在第一次被求值时存成一份快照同一帧内后续再有别的节点引用它直接读取快照不再往上游跑。这样移动状态机每帧只需要真正求值一次后面接三个、四个消费者都只拿快照。打个不太严谨的比方状态机是厨房Output 是刚出锅的菜。你以为把同一道菜的菜谱发给三个客人就能一次做好三份实际上如果没有缓存厨房会按照菜谱重新炒三遍。Cache Pose 相当于提前把菜盛好放在保温柜里谁要就直接端不用再开火。当然它缓存的是“整个姿势”不是某个骨骼或某个混合的局部结果。所以使用场景很明确当同一个子图的输出要被多个下游节点引用而这个子图本身的求值成本又不低时用 Cache Pose 包住它最合适。2. Cache Pose 节点入门位置、用法与命名2.1 在哪找节点怎么连如果你还没用过这个节点操作步骤其实很少打开动画蓝图 AnimGraph。在节点搜索框输入“Cache Pose”拖入图中。把它连到需要复用的姿势链路上。一般来说是放在某个状态机输出之后、后续分支开始之前。选中节点在细节面板中重命名。我习惯用“CachePose_”做前缀比如 CachePose_BaseMove。把原本从状态机输出接出去的线全部改接到这个 Cache Pose 的输出引脚上。这里有个容易被忽略的点Cache Pose 不是一个“自动替换所有引用”的开关它只是一个需要手动接入的节点。你必须在接入后手动把下游节点的输入引脚重新连接否则原来的连线还指向旧节点缓存没有覆盖到。2.2 Cache Bone 与 Cache Pose 的分工很多教程会把 Cache Bone 和 Cache Pose 一起提但两者的粒度完全不同。Cache Pose 缓存的是整个姿势结果适合缓存状态机输出这种大块头Cache Bone 缓存的是骨骼空间里的某个骨骼变换通常用在多个 IK 节点、多个后处理节点都要读取同一块骨骼数据时。实际项目里两者可以组合用Cache Pose 缓存基础移动Cache Bone 缓存手部骨骼再分给不同 IK 求解器。需要记住的是二者都是“同一帧内的复用”不是跨帧缓存。2.3 为什么命名和注释不是小事我在真实项目里踩过一个很浪费时间的坑优化完的动画蓝图里放了三个 Cache Pose名字全是默认的“CachePose”没人知道哪个缓存的是基础移动哪个缓存的是瞄准姿势。结果 UI 调到一半找错了节点改了缓存内容角色动画变得莫名其妙。从那以后我给自己定了两条规矩第一所有缓存节点必须用业务语义命名比如 CachePose_BaseMove / CachePose_AimPose第二在 AnimGraph 里用注释框把缓存区框起来写上类似“CACHE基础移动只计算一次”的说明。这样过几个月再回来维护哪怕只看了注释框也能立刻恢复上下文。3. 实战用缓存姿势改造一个角色蓝图3.1 优化前找出重复开销拿我当时处理的模拟项目举例。角色有地面移动状态机包含站立、走路、跑步三个状态每个状态里都做了上下半身混合角色肩膀上还有一把武器需要瞄准叠加另外有换弹动画和蹲伏覆盖。原始 AnimGraph 的接法很常见移动状态机输出同时被三个节点引用分别是 Layered Blend Per Bone、Blend by Bool、Slot 蒙太奇插槽。优化前我先做了一次性能定位。使用的工具是 Unreal Insights进入 PIE 模式打开 Insights勾选动画相关 channel让角色循环播放一段包含走路、跑步、瞄准、蹲伏的动作抓帧后进入 Animation Insights查看 AnimGraph 总耗时和节点耗时分布。结果很清楚AnimGraph 每帧总耗时 2.6ms 左右其中移动状态机相关的重复求值占了很大比重。这个数据一出来改方案就变得顺理成章给状态机输出加缓存。3.2 确定缓存位置确定缓存位置的原则是缓存放在被多个消费者共享的“公共上游”之后。对当前蓝图公共上游是移动状态机消费者是三个下游节点所以缓存尽量贴近状态机输出但不要包到状态机内部。改完之后节点逻辑变成这样StateMachine_BaseMove - CachePose_BaseMove - LayeredBlendPerBone上半身瞄准叠加 - BlendByBool蹲伏/站立切换 - SlotNode换弹等蒙太奇文字描述一下移动状态机每帧只求值一次输出写入 Cache Pose后面三个分支分别读取这份快照。Layered Blend Per Bone 用 CachePose_BaseMove 作为基础姿势再叠加上半身瞄准Blend by Bool 根据动画蓝图里的 bool 变量决定输出蹲伏还是默认跑动姿势Slot 节点则负责播放换弹这类蒙太奇。3.3 改造后的接线方法先看 Layered Blend Per Bone。把这个节点拖进 AnimGraph 后需要指定分支骨骼比如手臂骨骼然后设置叠加姿势的来源。这里把 Local Pose 输入接到 CachePose_BaseMove叠加姿势接瞄准相关的姿势序列或 AimOffset。这样每次手臂被叠加时拿到的底座是这份缓存快照而不是让状态机再算一次。再看 Blend by Bool。它是根据条件二选一的节点布尔输入可以接动画蓝图的变量比如 bIsCrouching。True 分支放蹲伏动画False 分支放 CachePose_BaseMove。使用缓存后当角色蹲下再站起来基础移动状态机不会被重复跑只有选择结果在变化。最后是 Slot 节点。Slot 节点的作用是播放动画蒙太奇比如换弹、挥手。把 Slot 的输入接到 CachePose_BaseMove蒙太奇播放时会临时覆盖基础姿势蒙太奇结束又回到缓存的移动姿势。这里顺序上我一般把 Slot 放在 Layered Blend 和 Blend by Bool 之后也就是到输出姿势的最后一步避免蒙太奇播放时被后续混合节点再叠一层。改完之后的实测数据本机场景仅供参考指标优化前优化后AnimGraph 每帧耗时2.6ms1.1ms移动状态机求值次数/帧3 次1 次游戏线程帧率85fps102fps3.4 一个容易踩的坑缓存层级不对有一个很常见的错误做法是把 Cache Pose 直接塞进状态机内部比如在走路、跑步每个状态里都放一个 Cache Pose。这会让状态机内部的混合和时间采样变得混乱尤其是过渡动画播放时不同状态可能各自保留自己的缓存快照结果看起来像角色“卡顿”或“瞬移”。正确做法是把缓存放在状态机输出之后状态机内部的逻辑保持原样让它正常处理状态切换输出的结果由缓存统一接管。4. 常见问题与排查技巧实录4.1 加了缓存后动画“定住”了这是初学者最容易遇到的。现象是某个动态效果比如换弹蒙太奇、面部表情变化加了 Cache Pose 后不再播放像被冻结在某一段。排查思路很简单看看这个动态分支在拓扑上是不是被缓存包住了。如果 Slot 节点本身位于 Cache Pose 的上游或内部那么缓存快照里记录的只是第一帧求值结果后续动态播放当然不会更新。解决方式是把 Slot 等重要动态节点移到缓存外部用 Cache Pose 只保存静态底座。4.2 加了缓存后反而更卡我也遇到过反向效果。原因通常有两个第一被缓存的子图本身太简单求值成本很低但 Cache Pose 节点本身也要维护缓存得不偿失第二被缓存的子图包含大量动态骨骼修改、物理模拟、IK 求解这些内容即使在缓存内也仍然需要每帧更新缓存并没有减少实际开销反而增加了额外管理。判断方法仍是用 Profiler如果加了缓存后节点调用次数没有明显下降或者 Animation 总耗时没有下降就说明缓存位置不对或粒度不对。4.3 状态机过渡表现异常表现是角色从走路切到跑步时过渡动画出现“迟滞”或“不连续”。排查后一般会发现问题不在 Cache Pose 本身而是把它放得过于靠近状态机内部干扰了过渡时间的采样。状态机内部有自己的一套时间推进和混合机制缓存不应该打断这个过程。安全做法是把它放在状态机输出端并且不要在过渡相关链路上共用两个不同的缓存名。4.4 版本和调试工具差异Cache Pose 在 UE4.26 到 UE5 系列里行为一致性还不错。调试时我推荐优先用 Unreal Insights 的动画通道比控制台命令更直观。控制台命令也可以配合用stat anim观察动画系统整体耗时stat unit看游戏线程、渲染线程、GPU 的帧耗时。需要提醒一点在 Debug 状态下动画蓝图可能走不到最优路径数据会比运行版本偏高所以对比优化效果时要用同一套场景和同一套配置否则很容易误判。4.5 常见问题速查表现象可能原因排查建议解决方案动态动画被冻结Slot/动态混合被包进缓存内部检查拓扑关系把动态节点移到缓存外性能没有下降缓存粒度不对或子图太简单抓帧对比调用次数取消缓存或调整边界过渡动画异常缓存放在状态机内部查看状态机内部连接移到状态机输出之后找不到对应缓存节点命名不清晰检查细节面板统一命名加注释框5. 从缓存姿势到动画蓝图整体性能调优5.1 Cache Pose 和 Cache Bone 组合使用在比较复杂的人形角色里上下半身往往有不同的逻辑。比如角色持枪瞄准时上半身要做瞄准叠加下半身要保留移动状态。这种情况下移动状态机的输出用 Cache Pose 缓存一份同一帧里如果上半身多个节点都要读取手臂骨骼变换再配合 Cache Bone 缓存手臂骨骼。这样整条主链路只求值一次骨骼缓存又减少了 IK 和多路后处理之间的重复读取。两者不是替代关系而是配合关系。5.2 一帧内缓存与跨帧更新的界限需要反复强调的是Cache Pose 缓存的生命周期只有一帧。它解决的是“同一帧里多处引用导致重复求值”的问题不是“让某个姿势在后续帧里都保持不变”的问题。如果你希望角色在远处降低动画更新频率那是另一套机制比如骨骼网格体的更新策略或 LOD。不要把两者混在一起理解。我之前见过有人试图用 Cache Pose 做跨帧帧率优化结果角色动作变得断断续续这就是用错了工具。5.3 什么时候不值得用 Cache Pose不是所有 AnimGraph 都需要加缓存。如果某个子图只有一个下游消费者或者子图本身是单个 Pose 节点加上 Cache Pose 基本没有收益反而增加节点数。更好的做法是先跑一遍 Profiler找到引用次数高、耗时占比大的子图再有针对性地加缓存。我在实际优化中通常先保留一张原始的拓扑截图然后每加一个缓存节点就在性能数据里做一次前后对比。这样做几次之后就能积累出比较清晰的使用直觉。最后分享几个偏个人的体会。第一次用 Cache Pose 时我图省事把一个 Slot 所在的整段链路都包进了缓存结果所有蒙太奇都不播了排查了将近两个小时才发现是拓扑位置的问题。后来我习惯在动手之前先画一张简单的数据流图把“哪个姿势需要复用、哪些节点必须动态更新”标清楚再进 AnimGraph 接线。另一个比较实用的习惯是给所有缓存节点统一加“CachePose_”前缀并把它们放在同一个注释框里注释框里写上“此区域只计算一次改动需谨慎”。这套做法不仅让自己少踩坑也方便后来接手的同事一上来就能看懂整张图。如果你现在正好被动画蓝图性能问题卡住建议不要急着删节点或优化美术资源先抓一帧性能数据看看是不是同一个状态机在反复求值。很多时候一个 Cache Pose 放在正确的位置就够用了。