1. 从一个被忽略的细节说起：为什么你的缩放动画看起来“不对劲”

做Unity项目的人，几乎都碰过物体缩放的需求。UI弹窗要从小变大、道具拾取要有个“弹一下”的反馈、场景里的机关要缓缓展开、角色受击要有个瞬间的形变——这些场景背后都是同一个动作：改变Transform的localScale。看起来简单到不能再简单，一行代码就能搞定，但我见过太多项目里，缩放动画要么像机器人一样生硬，要么像喝醉了酒一样忽快忽慢，要么在低帧率设备上直接“跳帧”闪一下。

问题出在哪？绝大多数情况下，不是代码写错了，而是没有区分“匀速”和“变速”这两种本质不同的运动模型，更没有理解Unity在每一帧背后到底做了什么。很多人拿到需求的第一反应是“用DOTween吧”，或者“挂个Animator吧”，这当然没错，但如果你连底层那几行数学都没搞清楚，一旦遇到需要动态调整、需要和物理系统配合、需要在特定帧精确控制的场景，就会立刻抓瞎。

这篇内容就是围绕“Unity3D缩放的匀速与变速简单应用”这个主题，把我这些年在这个看似最基础的功能上踩过的坑、总结出来的套路，完整地摊开讲一遍。不管你是刚接触Unity不久的新手，还是已经写过不少动画逻辑的老手，我相信里面关于帧率无关性、缓动函数选型、插值方式对比这几个点的讨论，都能给你一些直接能拿去用的东西。全文会从最朴素的匀速缩放讲起，再过渡到变速缩放的几种实现路径，最后落到实际项目里怎么选、怎么调、怎么避坑。代码以C#为主，全部可以直接复制到你的项目里跑起来。

2. 匀速缩放：最朴素也最容易写错的那几行代码

2.1 匀速缩放的数学本质与帧率陷阱

匀速缩放，说白了就是单位时间内缩放量的变化是恒定的。假设一个物体从scale 1变到scale 2，耗时1秒，那么在第0.5秒时它的scale应该是1.5。这个线性关系用公式表达就是：

currentScale = startScale + (targetScale - startScale) * (elapsedTime / duration)

看起来无懈可击。但很多人写出来的代码是这样的：

void Update() { transform.localScale += Vector3.one * 0.1f; }

这段代码的问题在于，它把“每帧增加固定量”当成了匀速。在60帧的设备上，一秒增加6.0；在30帧的设备上，一秒只增加3.0。同一个物体，在高性能手机上1秒缩放到目标，在低端机上要2秒，而且缩放的“速度感”完全不一样。这就是典型的帧率依赖问题。

正确的做法是把时间作为驱动量，而不是把帧数作为驱动量。下面是一个标准的匀速缩放实现：

using UnityEngine; public class LinearScale : MonoBehaviour { public Vector3 targetScale = Vector3.one * 2f; public float duration = 1f; private Vector3 startScale; private float elapsed = 0f; private bool isScaling = false; void Start() { startScale = transform.localScale; isScaling = true; } void Update() { if (!isScaling) return; elapsed += Time.deltaTime; float t = Mathf.Clamp01(elapsed / duration); transform.localScale = Vector3.Lerp(startScale, targetScale, t); if (t >= 1f) { isScaling = false; transform.localScale = targetScale; } } }

这段代码里有几个细节值得说。第一，用Time.deltaTime累加而不是用Time.time直接算，是为了让缩放可以在任意时刻开始而不受全局时间影响。第二，Mathf.Clamp01保证t不会超过1，避免插值溢出。第三，结束时强制把scale设为targetScale，这是因为浮点累加可能有微小误差，不强制赋值的话物体可能永远差那么零点零零几。

提示：如果你的项目里时间缩放（Time.timeScale）会被修改，比如暂停菜单把timeScale设为0，那么用Time.deltaTime累加的方案会自动暂停，这通常是我们想要的行为。但如果你希望缩放不受暂停影响，就要改用Time.unscaledDeltaTime。

2.2 Lerp与Slerp在缩放场景下的选择

Unity提供了两个常用的插值函数：Vector3.Lerp和Vector3.Slerp。在缩放场景下，绝大多数时候我们用Lerp就够了，因为缩放本质上是三个轴向上的独立数值变化，线性插值符合直觉。但有一种情况值得考虑Slerp：当你希望缩放过程中保持某种“球形过渡”的感觉时。

不过说实话，在localScale这个具体场景里，Slerp带来的视觉差异微乎其微，反而多了一次向量归一化和角度计算的开销。我的建议是：缩放一律用Lerp，除非你有非常特殊的艺术需求，否则没必要引入Slerp的额外复杂度。

真正需要留意的是另一个问题：非均匀缩放下的插值。假设一个物体初始scale是(1, 2, 1)，目标是(3, 1, 2)，用Lerp插值会分别对x、y、z三个分量做线性过渡，这是符合预期的。但如果你用Vector3.Lerp的同时又对物体做了旋转，而父级还有非均匀缩放，就可能出现“剪切”变形。这是Unity变换层级的一个经典坑，和插值函数本身无关，但排查起来很费时间。

2.3 一个容易被忽视的收尾问题：浮点精度与最终状态

前面提到结束时强制赋值，这里再展开说一下。浮点数在累加过程中会产生误差，尤其是当duration很长、帧率很高的时候，elapsed累加几千次之后可能和真实时间有微小偏差。更关键的是，Vector3.Lerp(start, target, t)在t接近1但不等于1时，结果和target之间会有肉眼不可见但代码可检测的差距。

如果你的后续逻辑依赖transform.localScale == targetScale这个判断，比如“缩放完成后触发某个事件”，那么不强制赋值就可能导致事件永远不触发。我一般会在缩放结束的判定里用t >= 1f而不是elapsed >= duration，并且在结束分支里显式赋值。这是一个很小的习惯，但能省掉很多“为什么回调没执行”的调试时间。

另外，如果缩放会被频繁打断和重启，比如快速连点按钮让弹窗反复弹出，那么每次重启时都要重新记录startScale = transform.localScale，而不是用最初的那个startScale。否则物体会从当前位置“跳”回最初的起点，视觉上非常突兀。

3. 变速缩放：让动画有“呼吸感”的几种实现路径

3.1 缓动函数的本质：把线性t映射成非线性t

变速缩放的核心思路其实一句话就能说清：先算出线性的进度t，再用一个函数把t映射成t'，最后用t'去做插值。这个映射函数就是缓动函数（Easing Function）。匀速缩放用的是t' = t，而变速缩放用的是各种曲线，比如：

• 缓入（Ease In）：t' = t * t，开始慢，后面快
• 缓出（Ease Out）：t' = 1 - (1 - t) * (1 - t)，开始快，后面慢
• 缓入缓出（Ease In Out）：t' = t * t * (3 - 2 * t)，两头慢中间快

这些函数的值域都是[0, 1]，定义域也是[0, 1]，所以可以无缝替换掉线性t。下面是一个用缓入缓出做缩放的例子：

void Update() { if (!isScaling) return; elapsed += Time.deltaTime; float t = Mathf.Clamp01(elapsed / duration); float easedT = t * t * (3f - 2f * t); // SmoothStep transform.localScale = Vector3.Lerp(startScale, targetScale, easedT); if (t >= 1f) { isScaling = false; transform.localScale = targetScale; } }

注意这里判断结束用的是原始的线性t，而不是easedT。因为easedT在t=1时也等于1，两者等价，但用线性t更直观，也避免了某些缓动函数在边界处的数值问题。

3.2 不用第三方库，手写一个可配置的缓动系统

项目里如果到处散落着t * t、1 - (1-t)*(1-t)这样的魔法公式，维护起来会很痛苦。更好的做法是定义一个枚举和一张映射表，把缓动类型和对应的函数关联起来。下面是我在多个项目里用过的一个轻量方案：

public enum EaseType { Linear, EaseInQuad, EaseOutQuad, EaseInOutQuad, EaseInCubic, EaseOutCubic, EaseInOutCubic, EaseOutBack, EaseOutElastic } public static class EaseUtility { public static float Evaluate(EaseType type, float t) { t = Mathf.Clamp01(t); switch (type) { case EaseType.Linear: return t; case EaseType.EaseInQuad: return t * t; case EaseType.EaseOutQuad: return 1f - (1f - t) * (1f - t); case EaseType.EaseInOutQuad: return t < 0.5f ? 2f * t * t : 1f - Mathf.Pow(-2f * t + 2f, 2f) / 2f; case EaseType.EaseInCubic: return t * t * t; case EaseType.EaseOutCubic: return 1f - Mathf.Pow(1f - t, 3f); case EaseType.EaseInOutCubic: return t < 0.5f ? 4f * t * t * t : 1f - Mathf.Pow(-2f * t + 2f, 3f) / 2f; case EaseType.EaseOutBack: float c1 = 1.70158f; float c3 = c1 + 1f; return 1f + c3 * Mathf.Pow(t - 1f, 3f) + c1 * Mathf.Pow(t - 1f, 2f); case EaseType.EaseOutElastic: if (t == 0f || t == 1f) return t; float c4 = (2f * Mathf.PI) / 3f; return Mathf.Pow(2f, -10f * t) * Mathf.Sin((t * 10f - 0.75f) * c4) + 1f; default: return t; } } }

有了这个工具类，缩放逻辑就可以写成：

float easedT = EaseUtility.Evaluate(easeType, t); transform.localScale = Vector3.Lerp(startScale, targetScale, easedT);

这样切换缓动类型只需要改一个枚举值，不用动核心逻辑。EaseOutBack和EaseOutElastic这两个函数特别适合做“弹一下”的效果，前者会稍微超过目标值再回来，后者会像弹簧一样震荡几次。用在UI按钮反馈、道具拾取上，手感比单纯的缓出好很多。

3.3 变速缩放的三种触发方式：Update驱动、协程驱动、动画曲线驱动

同样是变速缩放，触发方式不同，适用场景也不同。我把它归纳成三种：

第一种是Update驱动，就是上面那种在Update里累加时间的写法。优点是控制粒度最细，可以随时暂停、反转、修改目标值；缺点是每个缩放对象都要挂一个MonoBehaviour，对象多了之后Update的开销会累积。

第二种是协程驱动，用yield return null或者yield return new WaitForSeconds来推进。协程写起来更直观，适合一次性的、不需要中途干预的缩放。但协程的坑在于：如果物体被禁用（SetActive(false)），协程会直接停掉，而且不会自动恢复。另外协程里用Time.deltaTime同样受timeScale影响，需要留意。

第三种是动画曲线驱动，用AnimationCurve在Inspector里可视化地编辑缩放曲线。这是最“美术友好”的方式，策划和美术可以自己调曲线，不用改代码。缺点是曲线是烘焙在资源里的，运行时动态修改比较麻烦。

public AnimationCurve scaleCurve; void Update() { elapsed += Time.deltaTime; float t = Mathf.Clamp01(elapsed / duration); float curveValue = scaleCurve.Evaluate(t); transform.localScale = Vector3.Lerp(startScale, targetScale, curveValue); }

AnimationCurve的好处是你可以把曲线调成任意形状，包括先缩小再放大这种“预备动作”，这是纯数学缓动函数很难表达的。如果你的项目里有美术参与调手感，强烈建议用这种方式。

4. 实战中的选型与调参：什么场景该用哪种缩放

4.1 UI弹窗、道具反馈、场景机关：三类场景的缩放策略对比

缩放虽然是一个动作，但不同场景对它的要求差别很大。我按经验把它分成三类，每类的选型和参数都不一样：

UI弹窗用EaseOutBack是因为它有一个轻微的“过冲”效果，弹窗会稍微超过目标尺寸再回弹，视觉上更有活力。但过冲幅度不能太大，EaseOutBack的默认参数c1=1.70158产生的过冲大约是10%，这个比例对UI来说刚好。如果觉得太夸张，可以把c1调小到1.0左右。

道具反馈用EaseOutElastic是因为它震荡几次后稳定，很像真实的物理反馈。但要注意，弹性效果在低帧率下可能因为采样点太少而看起来“抖”，所以时长不能太短，0.2秒左右比较稳妥。

场景机关用EaseInOutCubic是因为它两头慢中间快，符合真实世界中重物启动和停止的惯性感。如果机关很重，时长可以拉到1.5秒以上，配合低沉的音效，沉浸感会强很多。

4.2 时长、幅度、曲线参数的联动调参法

很多人调缩放动画是“凭感觉”调，改完时长改幅度，改完幅度改曲线，来回折腾很久。我总结了一个更系统的调参顺序：先定时长，再定幅度，最后调曲线。

时长决定了动画的“节奏感”。0.1秒以内是“瞬间”，适合打击反馈；0.2到0.4秒是“快速”，适合UI交互；0.5到1秒是“正常”，适合大多数场景动画；1秒以上是“缓慢”，适合营造氛围。先把时长定在一个合理的区间，后面的调整才有基准。

幅度决定了动画的“力度”。从1缩放到1.1是“轻微”，1.2是“明显”，1.5以上是“夸张”。UI弹窗一般从0.8缩放到1.0，道具反馈从1.0到1.2再回1.0，场景机关可能是1.0到3.0甚至更大。幅度和时长要匹配：大幅度配长时长，小幅度配短时长，否则会显得突兀。

曲线决定了动画的“性格”。同样是0.3秒从0.8到1.0，用线性曲线是“机械”，用缓出是“自然”，用缓出回弹是“活泼”，用弹性是“俏皮”。曲线是在时长和幅度都定好之后，用来微调手感的最后一步。

注意：调参时一定要在目标设备上试，不要只在编辑器里看。编辑器的帧率通常很高，弹性效果看起来很顺滑，但在低端手机上可能因为帧率波动而出现卡顿感。我一般会在编辑器里把Game视图的帧率限制到30帧，模拟低端设备的效果。

4.3 缩放与其他动画的叠加：位置、旋转、透明度的协同

实际项目里，缩放很少单独出现。弹窗弹出时通常伴随透明度变化，道具拾取时通常伴随位置移动，机关启动时通常伴随旋转。这些动画叠加在一起时，如果各自用独立的Update驱动，很容易出现“各走各的”的割裂感。

我的做法是用一个统一的进度t驱动所有属性。比如弹窗动画，定义一个0到1的进度，然后用同一个t去驱动scale、alpha和位置偏移：

float t = Mathf.Clamp01(elapsed / duration); float easedT = EaseUtility.Evaluate(EaseType.EaseOutBack, t); transform.localScale = Vector3.Lerp(Vector3.one * 0.8f, Vector3.one, easedT); canvasGroup.alpha = Mathf.Lerp(0f, 1f, t); // 透明度用线性t，避免过冲导致alpha超过1 rectTransform.anchoredPosition = Vector2.Lerp(startPos, targetPos, easedT);

注意这里alpha用的是线性t而不是easedT，因为EaseOutBack会产生超过1的值，而alpha超过1虽然不会报错，但语义上不对，而且如果后续有基于alpha的判断逻辑可能出问题。这是一个很小的细节，但体现了“不同属性用不同曲线”的思路。

5. 那些年我在缩放上踩过的坑与排查实录

5.1 缩放不生效？先检查这四个地方

“代码明明写了，物体就是不变大”，这是新手最常遇到的问题。我按排查优先级列一下：

第一，检查是不是改错了Transform。如果物体有父级，而你改的是父级的localScale，子物体当然也会跟着变，但如果你期望的是只改子物体，就要确认改的是正确的那个Transform。更隐蔽的情况是，物体上挂了Layout Group或者Content Size Fitter之类的UI组件，它们会在LateUpdate里覆盖你设置的scale。

第二，检查是不是被Animator覆盖了。如果物体上有Animator，而且某个状态里包含了Scale曲线，那么Animator会在每一帧写入scale，你的代码设置会被覆盖。这种情况的典型表现是：在编辑器里手动改scale能看到变化，但一运行就弹回原样。解决办法是把Animator的Update Mode设为“Animate Physics”之外的模式，或者干脆把缩放逻辑也放进Animator里。

第三，检查是不是被物理系统干预了。如果物体上有Rigidbody，而且约束里勾选了Freeze Scale（某些版本有），或者父级有非均匀缩放导致物理引擎计算出问题，缩放可能表现异常。物理物体的缩放本来就容易出问题，建议尽量避免对带Rigidbody的物体做动态缩放。

第四，检查代码执行顺序。如果你在Update里设置scale，但另一个脚本在LateUpdate里又把它改回去了，那你的设置就白费了。Unity的执行顺序是Update → 协程（yield null之后）→ LateUpdate，所以如果两个脚本都在Update里改，顺序是不确定的。这种情况要么统一到一个脚本里，要么用LateUpdate确保最后执行。

5.2 低帧率下的缩放抖动：原因与三种缓解方案

低帧率下缩放抖动，本质上是采样点太少导致曲线被“折线化”。一个0.2秒的弹性动画，在60帧下有12个采样点，曲线看起来很顺；在20帧下只有4个采样点，弹性效果就变成了“跳一下、跳一下”。这不是代码bug，是数学上的必然。

缓解方案有三种。第一种是降低动画复杂度，在低端设备上把弹性效果换成简单的缓出，减少对采样点数量的依赖。第二种是提高动画时长，同样0.2秒的动画，在低帧率下延长到0.3秒，采样点数量会增加，曲线会更平滑。第三种是用固定时间步长驱动，不用Time.deltaTime累加，而是自己维护一个固定步长（比如1/60秒）的累加器，在Update里可能一次执行多步。这种做法能保证动画的数学精度，但实现起来复杂，而且如果帧率太低，一次执行多步反而会加重卡顿。

我的实际选择是：UI动画用第一种，场景动画用第二种，特殊需求才用第三种。大多数情况下，把弹性换成缓出、把时长稍微拉长，就能解决90%的低帧率抖动问题。

5.3 缩放与对象池的冲突：重置时机的选择

对象池是性能优化的常用手段，但和缩放动画配合时容易出问题。典型场景是：一个道具被拾取后播放缩放消失动画，然后回收到池里；下次从池里取出时，如果scale没有重置，道具会以“消失时”的尺寸出现，然后突然跳回正常尺寸。

问题的根源在于重置时机。如果在回收时重置scale，那么消失动画还没播完就被重置了，视觉上会闪一下。如果在取出时重置，那么从取出到重置之间有一帧的延迟，可能被玩家看到。

我的做法是：在回收时延迟一帧重置，或者在取出时立即重置并跳过第一帧的渲染。更稳妥的方案是，把缩放动画的结束状态直接设为“池中状态”，也就是消失动画结束时scale就是0，回收后不需要重置，取出时再播放一个从0到1的出现动画。这样整个流程是连续的，不会出现跳变。

// 回收时 public void ReturnToPool(GameObject obj) { obj.transform.localScale = Vector3.zero; // 直接设为0，作为池中状态 obj.SetActive(false); pool.Push(obj); } // 取出时 public GameObject GetFromPool() { GameObject obj = pool.Pop(); obj.SetActive(true); // 播放从0到1的出现动画 StartCoroutine(ScaleFromZero(obj)); return obj; }

这个方案的关键是让池中状态和动画结束状态一致，这样无论什么时候取出，都不会有视觉跳变。

5.4 一个真实的排查案例：为什么缩放动画在打包后变快了

这是我早期遇到的一个问题，印象很深。编辑器里测试一切正常，打包到设备上后，所有缩放动画都变快了，大概快了20%左右。代码没改，参数没改，就是打包后不一样。

排查过程是这样的：先怀疑是帧率问题，但动画用的是Time.deltaTime，理论上应该帧率无关。然后怀疑是timeScale被改了，检查了一遍没有。最后用日志输出Time.deltaTime和elapsed，发现设备上的Time.deltaTime比编辑器里小，但累加出来的elapsed却更大。

真正的原因是：编辑器的Game视图帧率不稳定，而设备上的帧率更稳定但更高。在编辑器里，Game视图可能跑在50帧左右，Time.deltaTime大约是0.02；在设备上跑满60帧，Time.deltaTime大约是0.0167。单帧看是设备更小，但设备每秒执行的帧数更多，所以同样1秒的动画，设备上累加的elapsed更接近真实时间，而编辑器里因为帧率波动，elapsed累加偏慢，动画看起来就“变慢”了。

这个案例给我的教训是：不要用编辑器的表现来校准动画时长。编辑器里的帧率受窗口大小、其他窗口遮挡等因素影响，波动很大。要校准时长，要么在目标设备上测，要么用Time.realtimeSinceStartup来对照。后来我养成了一个习惯：在动画开始时记录Time.realtimeSinceStartup，结束时再记录一次，打印出实际耗时，和设定的duration对比，这样能快速发现时间累加是否准确。

6. 把缩放逻辑封装成可复用的组件

6.1 一个ScaleTweener组件的完整实现

前面讲了这么多原理和坑，最后落到一个实际可用的组件上。下面这个ScaleTweener是我在多个项目里迭代出来的版本，支持匀速/变速、支持自定义缓动、支持完成回调、支持中途打断：

using UnityEngine; using UnityEngine.Events; public class ScaleTweener : MonoBehaviour { public Vector3 fromScale = Vector3.one; public Vector3 toScale = Vector3.one * 1.2f; public float duration = 0.3f; public EaseType easeType = EaseType.EaseOutBack; public bool playOnEnable = true; public bool useUnscaledTime = false; public UnityEvent onComplete; private float elapsed; private bool isPlaying; private Vector3 cachedFrom; void OnEnable() { if (playOnEnable) Play(); } public void Play() { cachedFrom = fromScale; elapsed = 0f; isPlaying = true; transform.localScale = cachedFrom; } public void PlayFromCurrent() { cachedFrom = transform.localScale; elapsed = 0f; isPlaying = true; } public void Stop() { isPlaying = false; } void Update() { if (!isPlaying) return; float dt = useUnscaledTime ? Time.unscaledDeltaTime : Time.deltaTime; elapsed += dt; float t = Mathf.Clamp01(elapsed / duration); float easedT = EaseUtility.Evaluate(easeType, t); transform.localScale = Vector3.Lerp(cachedFrom, toScale, easedT); if (t >= 1f) { isPlaying = false; transform.localScale = toScale; onComplete?.Invoke(); } } }

这个组件有几个设计上的取舍值得说明。fromScale和toScale都是公开字段，方便在Inspector里配置；PlayFromCurrent方法用于从当前scale开始播放，适合打断重播的场景；useUnscaledTime开关用于处理暂停菜单里的UI动画；onComplete用UnityEvent暴露给Inspector，策划可以自己挂回调，不用改代码。

6.2 组件化之后的性能考量与对象池适配

把缩放逻辑封装成组件之后，每个需要缩放的物体都会挂一个ScaleTweener，每个组件都有自己的Update。如果场景里有几百个这样的物体同时播放动画，Update的开销就不能忽视了。

优化的思路有两个。一是用管理器统一驱动，把所有活跃的Tweener注册到一个管理器里，由管理器的单个Update遍历更新。这样减少了Unity调用Update的虚函数开销，但增加了注册和注销的管理成本。二是用Job System或Burst，把插值计算放到多线程里，但这对于简单的缩放来说有点杀鸡用牛刀。

我的实际选择是：数量少于50个时用独立组件，超过50个时用管理器统一驱动。大多数项目里，同时播放缩放动画的物体不会超过这个数量，所以独立组件的方案足够用。真正需要担心性能的是粒子系统和大量UI元素的动画，那些场景有更专门的优化手段。

对象池适配方面，ScaleTweener的Play方法会重置elapsed和cachedFrom，所以从池里取出时调用Play就能正确播放。但要注意，如果物体在池里被禁用，OnEnable不会触发，所以要么在取出时手动调用Play，要么把playOnEnable设为true并确保取出时调用了SetActive(true)。

6.3 从缩放延伸到其他属性的通用Tweener思路

ScaleTweener的思路可以很容易地扩展到位置、旋转、颜色、透明度等属性。核心结构是一样的：记录起始值、累加时间、计算缓动、插值、结束回调。区别只在于插值的目标类型不同。

如果项目里这类动画需求很多，可以考虑写一个泛型的Tweener<T>基类，把公共逻辑抽出来，子类只实现插值部分。但要注意，Unity的Inspector对泛型支持不好，泛型类不能直接挂在GameObject上。所以实际做法通常是写一个非泛型的基类，用object或者Vector3作为通用类型，子类再转换。

不过说实话，对于大多数项目来说，直接写几个独立的Tweener组件（ScaleTweener、PositionTweener、FadeTweener）比搞一套泛型框架更简单直接。过度抽象反而会增加理解和维护的成本。我见过一些项目为了“通用”写了几百行的动画框架，结果用起来还不如直接写几行Lerp来得快。工具的目的是解决问题，不是展示架构能力。

7. 关于缩放这件事，我最后想分享的几个经验

缩放动画看起来是Unity里最基础的功能之一，但真正把它做“对”、做“好”，需要理解的细节比想象中多。从帧率无关性到缓动函数选型，从对象池适配到低帧率优化，每一个点背后都有实际项目里踩出来的教训。

如果只能记住一件事，我希望是：永远用时间驱动，不要用帧数驱动。Time.deltaTime是你最好的朋友，任何“每帧增加固定量”的写法都是定时炸弹，迟早会在某个设备上炸掉。

如果还能记住第二件事，那就是：缓动函数决定了动画的性格。同样的时长和幅度，换一个缓动函数，手感可能天差地别。多花十分钟试试不同的曲线，比事后反复调整参数要高效得多。

最后一个实用建议：给你的缩放动画加一个AnimationCurve的备选方案。当策划或美术说“这个感觉不对”的时候，让他们自己在曲线上拖两下，往往比你在代码里改半天更有效。把控制权交给最懂手感的人，这也是组件化设计的一个隐藏价值。