1. 手写BlendTree之前：先搞懂我们到底在解决什么问题
1.1 为什么放着现成的Animator Controller不用，非要写代码
Unity的Animator Controller里本身就自带BlendTree节点，右键Create State就能加，拖几个Clip进去调调threshold就能跑。那为什么还要手写？我刚开始接触这个需求时也这么想，直到被项目里连续几个状况折腾到破防。
第一个状况是动画帧率同步。竞技类游戏里角色移动和摄像机转向经常超过60帧，而Animator默认的更新频率会被Time.deltaTime带着走。一旦做帧同步或固定步长物理更新，Animator的采样时机就对不上了，角色会滑步。手写动画混合意味着我可以把混合计算放进FixedUpdate或者指定的Update循环里，用PlayableGraph精确控制采样时机。
第二个状况是状态数量。很多动作游戏一个角色同时有移动、转向、下蹲、持枪、换弹、受伤硬直这么多状态，如果每个状态都去Animator Controller里拉节点，编辑器里会变成一盘蜘蛛网。尤其当游戏里的AI角色有二十几种动作组合时，BlendTree的编辑界面会卡到怀疑人生。代码生成方案可以直接把角色管理器、动画资源和状态配置做成数据表，运行时自动构建动画图。
第三个状况其实是需求变更频率。项目开发中动作导演随时会改动画过渡的"手感"，编辑器里每次手动调整几十个threshold、映射曲线确实很直观，但版本管理不友好。手写代码后，这些调整全变成配置数据，可以在编辑器脚本里统一批量调参。只要做一套配置面板，策划改起参数来比在Animator窗口里点鼠标高效得多。
所以我的结论是：如果是个人demo或原型项目，用Animator Controller自带的BlendTree完全够用，设计上更省事。但当你需要把动画混合纳入代码驱动的角色状态机、需要做帧同步、需要批量调参时，手写BlendTree是更可持续的方案。这篇文章就按我自己项目里验证过的路线，从原理到代码把整个流程拆开讲清楚。
1.2 先分清BlendTree的四种类型，选错类型后面全白做
手写BlendTree之前，必须先弄明白Unity提供的混合类型各自适合什么场景。很多人一上来就拖节点点两下，结果走路和跑步的过渡生硬到没法看，其实就是混合类型选错了。Unity的BlendTree有四种主流类型：1D、2D Simple Directional、2D Freeform Directional、2D Freeform Cartesian，老版本的Direct类型在某些场合也还会用到，但现代项目里前三种已经能覆盖绝大多数需求。
1D是最基础的类型，适合只有一个参数驱动的线性混合，比如speed从0到1，动画从Idle到Walk再到Run。它做的事情本质上是分段线性插值，每个动画在参数轴上占一个threshold位置。手写的话就是一个简单的一维权重计算，用一个"前后最近的节点"找到插值比例。
2D Simple Directional主要用在方向性运动，最典型的就是"走路方向 + 移动速度"两个参数驱动多个方向的动画。比如你手上有Forward、Back、Left、Right四向走路的动画，外加一个Idle，2D Simple Directional会把它们铺在平面坐标系的四个方向上，距离原点越近的点权重越低。这个类型要求动画采样点大致分布在各个方向，不能有两个动画方向差异小于90度还希望单独生效。
2D Freeform Directional就比较自由，可以理解为允许同方向上有多个不同速度的动画。比如Forward Walk和Forward Run同时存在，它们在方向上一致但距离原点不同，系统根据当前速度参数在两者间插值。
2D Freeform Cartesian按两个轴独立计算混合，适合两个参数不体现方向、而是表示两个维度的量，比如"移动速度 x 倾斜角度"，或者"水平转向速度 x 垂直倾角"。这类混合在飞行游戏、滑板动作里很常见，两个轴的参数可以认为是正交的。
手写时最关键的差别在于权重计算方式。1D是简单的分段线性插值。2D Simple需要做基于角度的扇形权重计算。2D Freeform Directional则需要做Voronoi图或Delaunay三角剖分这类几何运算。如果你选的类型和角色需求不匹配，你会发现不管怎么调参数，混合结果都特别"脏"，所以在写代码前先把类型定准比什么都重要。
1.3 打个比方：BlendTree本质上是一堆"音量旋钮"
理解BlendTree最直观的方式是拿混音台打比方。一个混音台上有好几路推子，每路对应一个音轨，你推起哪一路，哪一路就出声，推子高度决定音量比例。BlendTree就是干这个的，只不过推子控制的不只是音量，还有动画的采样权重和姿势贡献度。
假设角色有一个Idle动画和一个Walk动画，当我们把权重设置成Idle占70%、Walk占30%时，角色最终呈现的姿势就是两个动画对应骨骼变换的加权结果。注意这里不是"先播完Idle再播Walk"，而是在每一帧里同时对两个动画采样，然后按权重插值骨骼的Position和Rotation。所以混合结果永远不会出现"明显的切换感"，只会有"姿态的渐变感"。
手写BlendTree代码的本质，就是用Playable API去复刻这套"混合台"逻辑，自己维护每个动画的权重。Unity的AnimationMixerPlayable就是混音台的核心，它能接收N个AnimationClipPlayable，然后你通过SetInputWeight逐个设置当前这帧每个输入占多少比例。实现时我会先算出一组权重数组，再一次性喂给Mixer。
比如你有一段四方向走路的需求，输入参数是移动方向量(x, y)，我计算权重时可以先找两个相邻方向的动画，算出它们之间的扇形夹角占比，再乘上一个总速度比例，这样不论角色朝哪个方向走，最终都是相邻两个动画按比例混合，而不是四路动画全都半死不活地掺在一起。这就是2D Simple Directional的核心思路。
2. BlendTree的核心算法与代码结构设计
2.1 1D混合的权重计算：从最原始的分段线性插值开始
写代码之前先把最简单的1D混合算法讲明白，因为后面所有复杂类型都建立在它的思想上。1D混合的基本前提是：你有N个动画Clip，每个Clip在参数轴上有一个位置p_i，当前参数值是p，你现在要确定每个Clip的权重w_i。最简单也最常用的方法是分段线性插值：找到参数p在哪个区间内，然后只让区间两端的动画参与混合。
假设我手上只有两个动画：Idle在speed=0位置，Walk在speed=1位置。当前speed=0.4，权重就是Idle占0.6，Walk占0.4。数学表达式是权重 = (p - p_left) / (p_right - p_left)。三个动画的情况也一样，先找到p落在哪两个threshold之间，然后对相邻两个动画算权重。
以下是1D混合权重计算的核心代码实现：
public float[] CalculateWeights1D(float[] thresholds, float currentValue) { int count = thresholds.Length; float[] weights = new float[count]; if (currentValue <= thresholds[0]) { weights[0] = 1f; return weights; } if (currentValue >= thresholds[count - 1]) { weights[count - 1] = 1f; return weights; } for (int i = 0; i < count - 1; i++) { if (currentValue >= thresholds[i] && currentValue < thresholds[i + 1]) { float range = thresholds[i + 1] - thresholds[i]; float t = (currentValue - thresholds[i]) / range; weights[i] = 1f - t; weights[i + 1] = t; break; } } // 归一化，防止浮点误差导致总和不为1 float sum = 0f; for (int i = 0; i < count; i++) sum += weights[i]; if (sum > 0f) { for (int i = 0; i < count; i++) weights[i] /= sum; } return weights; }这段代码要处理两个边界情况：当前值小于最小threshold、当前值大于最大threshold。实际项目中我还遇到过float精度导致的抖动，比如threshold等于0.4和参数0.40000001，区间判断会走到下一个区间去。所以后面我一般会加一个epsilon容错判断，大家实测时如果发现动画在某个临界点会闪一下，大概率就是这个问题。
2.2 2D Freeform Cartesian：双轴独立插值，权重像一张网
2D Freeform Cartesian的思路比1D复杂一些，但更灵活。它的核心思想是把两个轴视为两个独立的插值维度，每个动画在平面上有一个(x, y)坐标，当前的参数点也在平面上。最终权重可以理解为"当前点对周围动画点的插值贡献"。
一个实用做法是分两步：先在X轴方向上对每一列的动画做1D混合，得到一个临时权重；再在Y轴方向上对这些临时权重做1D混合。如果动画在平面上是规则网格排布的（比如横轴是速度0/5/10，纵轴是转向角-45/0/45），那么这个做法非常简单且高效。
但大多数情况动画点不是规则网格，而是散布在平面上的不规则点。这时我会用Delaunay三角剖分来算权重：把动画点连成三角网，找到当前参数点落在哪个三角形里，然后通过重心坐标算出三个顶点的权重。Delaunay的好处是三角型不会重叠，当前点总能找到唯一的三角形，权重总和保证为1。
手写Delaunay剖分代码比想象中长，核心是逐点插入算法。如果只是做简单项目，我建议直接用Unity的Mathd库或者开发包里的Triangle.NET。但如果你觉得引入外部库不值得，也可以用一种更讨巧的近似方法：对每个点算距离，然后用反距离加权（Inverse Distance Weighting），再归一化。
反距离加权代码很短，效果在动画点分布均匀时相当接近Delaunay：
public float[] CalculateWeightsIDW(Vector2[] points, Vector2 currentPoint, float power = 2f) { int count = points.Length; float[] weights = new float[count]; float[] distances = new float[count]; float totalInverse = 0f; for (int i = 0; i < count; i++) { float dist = Vector2.Distance(points[i], currentPoint); distances[i] = Mathf.Max(dist, 0.0001f); float inv = 1f / Mathf.Pow(distances[i], power); weights[i] = inv; totalInverse += inv; } for (int i = 0; i < count; i++) { weights[i] /= totalInverse; } return weights; }反距离加权的缺点是点密集区域会抢走过多权重，所以power值要调大一点，我一般用2或者3。但它是Delaunay方案完美落地前的过渡方案，如果只是个人项目或原型验证，完全够用。
2.3 2D Simple Directional：扇形权重计算，方向性手感的关键
对于角色移动这类最常见需求，2D Simple Directional才是真正的主角。它的输入是移动方向向量(x, y)，输出是各个方向动画的权重。算法核心是算出当前方向落在哪两个相邻方向动画之间，然后按夹角大小分配权重。如果参数点的位置反映出速度量级，还要再乘上一个总速度权重。
我之前项目的做法是：把方向动画的方向单位向量提前存好，然后在运行时计算当前输入向量与每个动画方向的点积，找出夹角最小的那个方向作为主方向，再找夹角第二小的作为辅助方向，确保这两个方向在圆上相邻，然后按夹角比例插值。如果输入向量的长度接近0，那直接让Idle动画权重为1就完事。
以下是方向权重计算的核心函数：
public void Calculate2DDirectionalWeights( Vector2[] directions, Vector2 inputDirection, float idleThreshold, out float[] weights, out float idleWeight) { int count = directions.Length; weights = new float[count]; float inputLength = inputDirection.magnitude; Vector2 dir = inputLength > 0.001f ? inputDirection.normalized : Vector2.zero; if (inputLength < idleThreshold) { idleWeight = 1f; for (int i = 0; i < count; i++) weights[i] = 0f; return; } int primaryIndex = -1; int secondaryIndex = -1; float primaryDot = -1f; float secondaryDot = -1f; for (int i = 0; i < count; i++) { Vector2 animDir = directions[i].normalized; float dot = Vector2.Dot(dir, animDir); if (dot > primaryDot) { secondaryDot = primaryDot; secondaryIndex = primaryIndex; primaryDot = dot; primaryIndex = i; } else if (dot > secondaryDot) { secondaryDot = dot; secondaryIndex = i; } } float angleBetween = Mathf.Acos(Mathf.Clamp(primaryDot * primaryDot + secondaryDot * secondaryDot - 1f, -1f, 1f)); if (angleBetween < 0.001f) { weights[primaryIndex] = 1f; } else { float primaryAngle = Mathf.Acos(Mathf.Clamp(primaryDot, -1f, 1f)); float secondaryAngle = Mathf.Acos(Mathf.Clamp(secondaryDot, -1f, 1f)); float totalAngle = primaryAngle + secondaryAngle; float primaryWeight = secondaryAngle / totalAngle; float secondaryWeight = primaryAngle / totalAngle; weights[primaryIndex] = primaryWeight; weights[secondaryIndex] = secondaryWeight; } idleWeight = 0f; }这套扇形算法我实测下来手感很好，角色朝任意方向走时，相邻两个方向动画的过渡都很自然。需要注意directions数组必须是按角度顺序排列的，否则"找相邻"会出错。我在项目里通常把四个方向的动画方向固定为(1,0), (0,1), (-1,0), (0,-1)，用一张配置表维护角度排序。
3. 用PlayableGraph搭建手写BlendTree完整工程
3.1 前置准备：AnimationClip的导入设置与动画绑定
写混合代码前，先把动画资源本身的骨头捋顺。大部分动画混合出问题，不是代码的问题，而是动画资源没准备好。核心三件事：骨骼一致、导入设置统一、动画长度基准一致。
骨骼一致是最基本的要求。如果四个方向走路动画的骨骼命名不一致，混合时会出现错位，模型会像被拆散了一样。从美术那里拿到动画后，我一般会在导入设置里检查Rig标签页，确保所有Clip绑定到同一个Avatar。我习惯把骨骼层级名做成规范，比如pelvis、spine_01、spine_02这种，方便运行时做额外处理。
导入设置里需要注意Animation Compression。默认的"Keyframe Reduction"会在一定程度上压缩骨骼曲线，如果压缩率太高，混合时会出现抖动。我的经验是动画混合相关Clip用"Optimal"压缩，不要用"Keyframe Reduction"压到极低。实测下来Optimal压缩对混合手感影响最小。
动画长度基准一致这件事容易被忽略。如果一个动画是0.8秒，另一个是1.0秒，混合时如果不带speed mapping，角色速度会突然变快或变慢。我通常在Clip导入设置的Animation栏里调整Sample Rate和Loop Time，并匹配动画的长度。如果美术给的动画节奏确实不统一，也可以在BlendTree代码里通过AnimationClipPlayable的SetSpeed方法统一到同一速度，不过这会增加调试成本。
动画准备好之后，最好写一段简单的编辑器脚本检查所有Clip的绑定骨骼和动画时长，内容不多但能省下很多深夜排查时间。检查代码如下：
#if UNITY_EDITOR using UnityEditor; using UnityEngine; public class AnimationClipValidator : EditorWindow { [MenuItem("Tools/Animation/Validate Clips")] static void ValidateClips() { string[] guids = AssetDatabase.FindAssets("t:AnimationClip", new string[] { "Assets/Animations" }); foreach (string guid in guids) { string path = AssetDatabase.GUIDToAssetPath(guid); AnimationClip clip = AssetDatabase.LoadAssetAtPath<AnimationClip>(path); if (clip == null) continue; EditorGUILayout.LabelField(clip.name, clip.length + "s, " + clip.frameRate + "fps"); var bindings = UnityEditor.AnimationUtility.GetCurveBindings(clip); if (bindings.Length == 0) { EditorGUILayout.HelpBox("No curve data", MessageType.Warning); } } } } #endif这段工具代码能帮你在进入混合调试前先一眼看出哪些Clip可能是空的或者数据异常。我每次新建动画混合项目都会先跑一次这个校验，省去后面"动画为什么不生效"的排查时间。
3.2 搭建PlayableGraph：AnimationMixerPlayable与AnimationClipPlayable配合
现在进入手写BlendTree的核心环节：用Unity的Playable API搭建动画混合图。这套API是Unity 2018以后主推的动画管线，比传统的Animation.Play和Animator Component更底层、更可控。
PlayableGraph相当于一个动画播放管网，你可以往里面塞各种节点，然后把最终输出接到角色骨骼上。我先给出一段通用的图搭建代码，再逐步解释每个节点在做的事。
using UnityEngine; using UnityEngine.Animations; using UnityEngine.Playables; public class RuntimeBlendTree : MonoBehaviour { public AnimationClip idleClip; public AnimationClip walkClip; public AnimationClip runClip; private PlayableGraph graph; private AnimationMixerPlayable mixer; void Start() { graph = PlayableGraph.Create("RuntimeBlendTree"); graph.SetTimeUpdateMode(DirectorUpdateMode.GameTime); // 创建混合器，三个输入对应三个动画 mixer = AnimationMixerPlayable.Create(graph, 3); // 把每个Clip包装成AnimationClipPlayable并挂到混合器输入 var idlePlayable = AnimationClipPlayable.Create(graph, idleClip); var walkPlayable = AnimationClipPlayable.Create(graph, walkClip); var runPlayable = AnimationClipPlayable.Create(graph, runClip); graph.Connect(idlePlayable, 0, mixer, 0); graph.Connect(walkPlayable, 0, mixer, 1); graph.Connect(runPlayable, 0, mixer, 2); // 创建输出节点，绑定到当前角色的Animator var output = AnimationPlayableOutput.Create(graph, "Output", GetComponent<Animator>()); output.SetSourcePlayable(mixer); graph.Play(); } void Update() { // 每帧更新权重 float speed = 0f; if (Input.GetKey(KeyCode.W)) speed += 1f; if (Input.GetKey(KeyCode.S)) speed -= 1f; speed = Mathf.Clamp01(speed); // 手动实现1D混合：Idle为0，Walk为0.5，Run为1.0 float idleWeight = Mathf.Clamp01(1f - speed * 2f); float walkWeight = Mathf.Clamp01(1f - Mathf.Abs(speed - 0.5f) * 2f); float runWeight = Mathf.Clamp01((speed - 0.5f) * 2f); mixer.SetInputWeight(0, idleWeight); mixer.SetInputWeight(1, walkWeight); mixer.SetInputWeight(2, runWeight); } void OnDestroy() { if (graph.IsValid()) graph.Destroy(); } }这个例子把三个动画挂到同一个混合器上，运行时手动设置权重，效果等同于一个三段式1D BlendTree。重点是graph.Connect和mixer.SetInputWeight这两步：Connect把动画Clip接到混合器的输入口，SetInputWeight决定该输入口在当前帧占据多大权重。
3.3 权重映射：Mathf.SmoothDamp与曲线调整的细节
上一节的代码用了简单的线性映射，实际项目里线性映射手感通常太"硬"。角色从Idle走到Run，如果权重变化是线性的，视觉上看起来会像在"匀速滑动"。为了让动作过渡更自然，我一般会在代码里加一个SmoothDamp做时间域上的平滑，再用AnimationCurve对速度到权重的映射做非线性化。
SmoothDamp的作用是防止权重突变，它本质上是带阻尼的弹簧运动，比直接lerp更可控，不会出现超调。除了角色移动这种手感敏感的混合，UI动画和摄像机动画里也可以用它，凡是需要"数值平滑"的地方都能套。
我在项目里的标准做法是：
public class SmoothBlendParam { private float velocity = 0f; public float CurrentValue { get; private set; } public float Update(float target, float smoothTime, float deltaTime) { CurrentValue = Mathf.SmoothDamp(CurrentValue, target, ref velocity, smoothTime); return CurrentValue; } }然后每帧把原始输入值经过SmoothBlendParam平滑后，再送进权重计算函数。这样即使输入速度瞬间从0跳到1，混合权重也会经历一个可感知的加速过渡，而不是瞬间切换。
还有个细节是速度曲线。游戏里的移动速度通常不是匀速的，走路开机慢、跑步提速快，这些动态曲线如果做成AnimationCurve，在Inspector里调整非常直观。下面的代码演示了怎么用AnimationCurve驱动权重：
public AnimationCurve walkCurve; public AnimationCurve runCurve; void UpdateWeights(float normalizedSpeed) { mixer.SetInputWeight(0, walkCurve.Evaluate(normalizedSpeed)); mixer.SetInputWeight(1, runCurve.Evaluate(normalizedSpeed)); }我在真实项目里绝不会直接拖两个AnimationCurve作为权重曲线，因为曲线自己不能保证权重和为1。所以我一般让第一个曲线是主控曲线，第二个曲线是1减第一个曲线。这样能保证任意时刻两者权重之和为1，不会出现角色静止时还混合着跑动的效果。
3.4 手写2D方向混合的完整示例：让角色朝任意方向移动
现在把前面所有的内容拼起来，实现一个真正能跑起来的2D方向混合。这个示例假设角色有Idle、Forward、Back、Left、Right五个动画，输入是两个轴：horizontal和vertical，即摇杆或键盘方向。
我的思路是：先把输入向量标准化，如果长度小于阈值就完全播放Idle；否则利用之前写的Calculate2DDirectionalWeights算出四个方向动画的权重，再把权重乘以一个总速度系数（这里简化为1，实际项目中可以用速度曲线）。
完整代码如下，你可以直接挂到一个带Animator组件的角色模型上测试：
using UnityEngine; using UnityEngine.Animations; using UnityEngine.Playables; public class DirectionalBlendTree : MonoBehaviour { public AnimationClip idleClip; public AnimationClip forwardClip; public AnimationClip backClip; public AnimationClip leftClip; public AnimationClip rightClip; public float blendSmoothTime = 0.1f; private PlayableGraph graph; private AnimationMixerPlayable mixer; private Vector2[] directions = new Vector2[] { new Vector2(0f, 1f), new Vector2(0f, -1f), new Vector2(-1f, 0f), new Vector2(1f, 0f) }; private float idleWeight = 0f; private float[] weights = new float[4]; private SmoothBlendParam smoothX = new SmoothBlendParam(); private SmoothBlendParam smoothY = new SmoothBlendParam(); void Start() { graph = PlayableGraph.Create("DirectionalBlendTree"); graph.SetTimeUpdateMode(DirectorUpdateMode.GameTime); mixer = AnimationMixerPlayable.Create(graph, 5); var idlePlayable = AnimationClipPlayable.Create(graph, idleClip); var forwardPlayable = AnimationClipPlayable.Create(graph, forwardClip); var backPlayable = AnimationClipPlayable.Create(graph, backClip); var leftPlayable = AnimationClipPlayable.Create(graph, leftClip); var rightPlayable = AnimationClipPlayable.Create(graph, rightClip); graph.Connect(idlePlayable, 0, mixer, 0); graph.Connect(forwardPlayable, 0, mixer, 1); graph.Connect(backPlayable, 0, mixer, 2); graph.Connect(leftPlayable, 0, mixer, 3); graph.Connect(rightPlayable, 0, mixer, 4); var output = AnimationPlayableOutput.Create(graph, "Output", GetComponent<Animator>()); output.SetSourcePlayable(mixer); graph.Play(); } void Update() { float x = Input.GetAxisRaw("Horizontal"); float y = Input.GetAxisRaw("Vertical"); Vector2 input = new Vector2(x, y); // 平滑输入 float smoothXValue = smoothX.Update(input.x, blendSmoothTime, Time.deltaTime); float smoothYValue = smoothY.Update(input.y, blendSmoothTime, Time.deltaTime); Vector2 smoothInput = new Vector2(smoothXValue, smoothYValue); // 计算权重 CalculateWeights(smoothInput); mixer.SetInputWeight(0, idleWeight); for (int i = 0; i < 4; i++) { mixer.SetInputWeight(i + 1, weights[i]); } } private void CalculateWeights(Vector2 input) { float inputLength = input.magnitude; if (inputLength < 0.1f) { idleWeight = 1f; for (int i = 0; i < 4; i++) weights[i] = 0f; return; } idleWeight = 0f; Vector2 dir = input.normalized; // 计算方向夹角权重 for (int i = 0; i < 4; i++) { float dot = Vector2.Dot(dir, directions[i].normalized); weights[i] = Mathf.Max(0f, dot); } // 归一化方向权重 float sum = 0f; for (int i = 0; i < 4; i++) sum += weights[i]; if (sum > 0f) { for (int i = 0; i < 4; i++) weights[i] /= sum; } // 乘以速度系数 float speedFactor = Mathf.Clamp01(inputLength); for (int i = 0; i < 4; i++) weights[i] *= speedFactor; } void OnDestroy() { if (graph.IsValid()) graph.Destroy(); } }这段代码使用的方向权重算法非常朴素，但它胜在稳定且不依赖外部库。方向权重归一化之后，四个方向中两个相邻方向会占主要比例，另外两个方向权重很低，视觉上就能产生自然的转向混合效果。如果想更精确，可以把CalculateWeights替换成之前那套Calculate2DDirectionalWeights。
3.5 动画播放速度与循环设定：别让混合后的动作忽快忽慢
BlendTree混合的另一个坑是动画播放速度不一致。四个方向走路动画如果循环周期不同，混合起来角色会看起来一瘸一拐。我一般会在AnimationClipPlayable创建时设置播放速度和循环属性。
播放速度的配置方式有两种。一种是简单地在Clip导入设置里让所有动画时长一致，但这样会牺牲美术原始动画的节奏感。另一种是在代码里按动画长度比设置SetSpeed，保证所有Clip的周期对齐到同一个基准值。
我的推荐做法是：在项目前期就让所有移动动画使用相同的循环周期，比如Forward/Back/Left/Right都是0.8秒循环一次。这样混合后速度过渡自然，而且不需要额外的SetSpeed逻辑。如果确实需要修改，可以用下面的代码在运行时统一速度：
float baseLength = 0.8f; void NormalizeClipSpeed(AnimationClipPlayable playable, AnimationClip clip) { float speed = clip.length / baseLength; playable.SetSpeed(speed); }循环设置方面，AnimationClipPlayable默认会播放一次然后停在末尾。如果你的混合包含位移循环动画，必须在创建Playable之前把Clip的Loop Time勾上，或者用Playable的SetTime和SetDone去手动控制循环，否则混合到一半动画就停住不动了。我在项目里都是在编辑器导入阶段统一处理Loop Time和循环姿势，运行时不再做额外标记。
4. 手写BlendTree的常见问题与排错实战
4.1 动画不生效或始终停在第一帧
手写BlendTree最常见的坑就是"动画不动"，尤其是刚把PlayableGraph搭好运行时，角色一直保持T-Pose或第一帧姿势。这个问题的根源大概率不是混合器的问题，而是输出没有正确驱动骨骼。
首先检查AnimationPlayableOutput的Animator绑定是否正确。如果角色身上有Animator组件但绑定的GameObject不对，输出节点找不到动画目标，动画自然不生效。
其次检查是否调用了graph.Play()。PlayableGraph创建后默认不是播放状态，很多新手会忘记调用graph.Play()，结果动画就像被按了暂停键一样一直停在初始帧。这个问题排查方法很简单，在Update里打印mixer的GetInputWeight，如果权重正常但骨骼不动，那八成是Graph没播放。
第三是检查Animator组件是否被其他系统同时控制。如果你在写代码前没有把Animator Controller从角色上移除，或者Animator的runtimeAnimatorController还指着一个带状态的Controller，两个系统会同时写骨骼，结果就是相互覆盖、动画乱跳。我通常在Init时把角色Animator的runtimeAnimatorController强制置空，确保只有PlayableGraph在驱动。
第四是权重都为0。这是我早期经常犯的错误，权重计算函数里sum为0时没有正确兜底，导致所有通道权重为0，混合器输出空姿势。在权重计算函数末尾加一个"如果所有权重都接近0，则让第一个通道权重为1"的兜底，能省下大量调试时间。
4.2 混合结果跳变、不丝滑的原因与解决
动画跳变最典型的现象是：角色从Idle到Walk时，腿部动作会出现一次明显的"弹跳"或"闪切"。这个手感问题绝大部分来自权重变化太陡，或者相关Clip之间的骨骼相对位置差太大。
权重太陡的解法是我在3.3节里写的SmoothDamp方案。比如角色突然从静止跑到全速，target从0跳到1，实际权重以指数衰减速度慢慢爬升，视觉上就会舒服很多。smoothTime建议从0.05试到0.2，根据项目手感来调，太小没效果，太大角色动作会"肉"。
骨骼相对位置差太大需要从资源和混合逻辑两个方向解决。如果Idle是标准站立pose，Walk却是迈腿pose，两者叠加时脚的位置差很大，就会出现"脚滑步"。这种情况只能从美术侧修，要保证Idle和Walk的骨骼基准姿势接近，尤其要注意脚踝、骨盆的位置，或者混合时只混合上半身和下半身的一部分骨骼。
还有一个容易被忽略的原因是动画的root motion和骨骼变换冲突。如果Clip的Bake Into Pose设置不正确，位移被重复计算，混合后角色会在地板上滑来滑去。我的建议是，BlendTree使用的移动动画一律关闭root motion，在代码层统一控制角色位移，动画只管表现姿态。
4.3 性能优化：手写BlendTree会不会卡爆CPU
很多人在评估手写BlendTree时都会担心Playable API的性能。我的答案是：不会，前提是你别做蠢事。PlayableGraph本身经过Unity引擎优化，它的节点执行效率比传统Animation Component高得多，尤其适合大量角色同时播放不同混合动画的场景。
真正会拖垮性能的地方在于权重计算的频率和Clip数量。如果每帧你对100个角色做Delaunay三角剖分，即使角色总量不大也会产生明显GC压力。优化方向是：权重计算只在输入参数变化超过阈值时才执行，没有变化就复用上一帧的权重数组。
我的项目里加了一个脏标记机制：
private Vector2 lastInput; private bool inputDirty = true; void Update() { Vector2 currentInput = new Vector2(x, y); if (Vector2.Distance(currentInput, lastInput) > 0.001f) { inputDirty = true; lastInput = currentInput; } if (inputDirty) { RecalculateWeights(); inputDirty = false; } }这个简单优化在实际项目中能把每帧的CPU开销砍掉大半，因为玩家不会每秒几十次地改变方向输入，大部分帧的输入变化其实很小。
如果角色数量特别多，比如千人同屏，还可以把权重计算放到Job System里并行化，把每个角色的方向输入和权重输出都做成NativeArray，然后用IJobParallelFor批量计算。不过这个方案的复杂度会明显上升，我建议先做好脏标记优化，真的不满足性能指标再上Job System也不迟。
4.4 我的习惯总结与几个实用小技巧
写BlendTree代码几年下来，我最大的体会是：动画混合的本质是"权重管理"，而权重管理的本质是"参数到权重的映射"。不管是1D还是2D，不管用什么算法，终极目标都是让权重的变化符合人的视觉直觉。技巧再炫，如果观众看起来不舒服，一切都是白搭。
分享几个实操中的小技巧。第一，调试时给权重计算加可视化。在Scene视图里用Gizmos把每个动画的方向和当前权重画出来，或者用Debug.Log输出权重数组，能极大加快排查速度。第二，把重要参数（smoothTime、weight曲线、方向夹角）全部暴露成SerializeField，在Inspector里实时调，比改代码方便太多。第三，做角色数量多的项目时，提前设计好权重缓存机制，避免每帧重复计算，这是性能优化的第一道关。
还有一个小技巧我觉得特别有用，就是在权重计算里加入一个"死区"参数。角色摇杆轻微晃动时，如果没有死区，角色会一直轻微切换各个方向的混合，看起来像抽风。我通常把输入幅度小于0.15的Input统一判定为0，这样操作回中时角色能稳定回到Idle，手感会扎实很多。
