企业官网建设流程全解析

玩Unity的应该都跟DOTween打过交道，这个补间动画插件几乎成了UI动画和物体运动的标准选择。但我发现一个很有意思的现象：很多人写DOTween动画时会写OnComplete回调，却没想清楚"它到底在什么时候触发"。DOTween中回调函数的触发时机这个话题，看起来简单，实际上一踩就是一个坑。比如循环动画里OnStart只触发一次，OnComplete却每循环都触发；Kill掉一个补间还会触发OnKill；调用了SetAutoKill(false)之后补间还活着，回调又会漏触发。这些细节不搞清楚，调动画的时候就会被诡异的时序折腾到怀疑人生。

这篇文章我把DOTween里所有回调函数的触发时机一次性梳理清楚，包括基础的回调节点、外部操作对回调的影响、时间缩放和嵌套补间的坑、以及我平时排查回调问题的流程。适合刚接触DOTween的初学者，也适合写了一半动画回来救场的资深开发。接下来直接用代码和实际运行顺序说话。

1. 先认识DOTween的回调家族

1.1 老三样：OnStart、OnUpdate、OnComplete

DOTween在为任何对象做补间时，最常见的三个回调就是OnStart、OnUpdate、OnComplete。它们各自负责动画生命周期里的某个固定节点，理解它们就是理解回调时机的地基。

OnStart的触发时机实际上很巧妙。它不是在创建补间的那一刻触发，而是在补间真正开始播放的第一个更新帧触发。这是什么意思？比如你写了一段代码：

transform.DOMove(new Vector3(0, 3, 0), 1f) .OnStart(() => { Debug.Log("OnStart"); }) .OnUpdate(() => { Debug.Log("OnUpdate"); }) .OnComplete(() => { Debug.Log("OnComplete"); });

这段代码在运行到的时候，OnStart不会立刻打印。真正打印发生在下一帧DOTween开始推进这个补间时。如果你的补间前面设置了SetDelay(2f)，那OnStart要等到延迟结束、补间真正开始动的那一刻才会触发。这一点和大家的第一印象相反，很多人以为创建Tween的瞬间就会触发OnStart，实际上并不是。

OnUpdate是每一帧补间更新时触发，频率和DOTween的更新模式相关。默认情况下它跟随游戏的主循环，每帧更新一次，所以OnUpdate也会每帧执行一次。调试时很容易用OnUpdate打印当前进度，比如把补间的position值打印出来。但要注意，如果补间被Pause暂停，OnUpdate不会继续触发，因为暂停状态下DOTween不会对这个补间做任何推进。

OnComplete的含义相对明确，它表示整个补间已经跑到了终点，全部播放完毕。这个"全部播放完毕"有一个边界条件：如果你设置了SetLoops(3)，那么OnComplete不会在第1个循环结束的时候触发，而是等3个循环全部跑完，最后一次循环结束才触发。这一点在循环动画中特别容易踩到，下面会重点展开。

1.2 小众但好用的回调：OnKill、OnStepComplete、OnPause

除了老三样，DOTween还提供了几个容易被忽略的回调：OnKill、OnStepComplete、OnPause、OnPlay、OnRewind、OnWaypointChange。它们不是每次都用，但用上的时候基本都是在处理特殊时序。

OnKill表示补间被销毁时触发。这里的关键点在于，无论这个补间是自然播放完被自动Kill，还是你在中途手动调用tween.Kill()，都会触发OnKill。很多人的误区是认为只有手动Kill才触发，实际上DOTween默认autoKill为true，补间播放完毕会立刻把自己销毁，此时OnKill也会被触发。所以如果你在OnComplete里写了一段逻辑，又在OnKill里写了一段逻辑，实际运行时会发现OnComplete和OnKill几乎是连着触发的。

OnStepComplete是循环相关的回调。当你的补间设置了SetLoops，每完成一次循环都会触发一次OnStepComplete。比如循环3次，OnStepComplete会触发3次。而OnComplete只在最后一次循环结束触发。两者在最后一次循环时的触发顺序是OnStepComplete先触发，紧接着OnComplete触发。这个顺序我实测过很多次，稳定可靠。

OnPause和OnPlay是反面的一对。OnPlay在补间从暂停或初始状态被播放时触发，OnPause在补间被暂停时触发。这里有一个有意思的地方：如果你在补间还没开始播放时调用Pause，OnPause不一定会触发，因为补间本来就不在播放状态。所以涉及Pause相关的回调时，建议先用IsActive()和IsPlaying()判断状态，再下结论。

1.3 回调的添加与叠加规则

DOTween的回调并不限制只能添加一个，你可以用追加的方式挂多个回调。比如OnComplete(() => A()).OnComplete(() => B())，只要链式调用时都写了OnComplete，两个lambda都会被保留并在补间完成时依次触发。这个行为在很多初学者看来像"覆盖"，但实际上DOTween内部维护了一个回调队列，追加的所有方法都会执行。

不过我建议不要过度堆叠回调。如果你在同一个补间上挂四五个OnComplete，代码的可读性会急速下降，调试时也难判断某个回调是从哪里挂上去的。我自己的习惯是，一个补间最多挂一个OnComplete，如果需要串联两个阶段，就在这个OnComplete里再去启动下一个补间，或者直接用Sequence组织多个子补间，让回调职责清晰一点。

2. 回调触发时机的基础逻辑

2.1 补间更新循环与触发节点

DOTween之所以能统一回调的触发顺序，是因为它内部有一个统一的更新循环。每次更新时，DOTween会检查所有活跃的补间，推进它们的进度，然后根据推进的状态发出对应的回调。

这个循环我们可以简单理解成一个流水线：补间对象被创建后进入活跃列表，每一帧DOTween遍历这个列表，对每个补间做三步处理。第一步判断是否处于Play状态，只有处于Play状态才推进进度；第二步在进度从0变为大于0的瞬间触发OnStart（如果之前没触发过）；第三步推进进度并触发OnUpdate，到达某个节点时再触发OnStepComplete或OnComplete。这几步的顺序在DOTween内部是固定的，所以回调之间不会出现随机先后。

实际上我们调试时可以不用看源码，用一个日志序列就能验证触发顺序。比如在补间上挂上OnStart、OnUpdate、OnStepComplete、OnComplete四个回调，然后跑一个SetLoops(2)的补间，日志会输出OnStart一次，OnUpdate每一帧一次，第一次循环结束时OnStepComplete一次，第二次循环结束时OnStepComplete一次后紧跟OnComplete。这个顺序看清楚之后，很多混乱就迎刃而解了。

2.2 延迟、循环次数对回调的影响

SetDelay是最容易改变回调时机的参数。延迟意味着补间虽然创建了，但在延迟期内完全不推进。这个阶段OnStart不会触发，OnUpdate也不会触发。注意不是触发值为0的更新，而是压根不触发。这个区别很关键，如果你用OnUpdate做累计计数，延迟期内计数会不动，容易误判为卡死。

循环次数对回调的影响主要在于OnComplete和OnStepComplete的触发次数。不循环时OnComplete只触发一次，OnStepComplete也触发一次，两者顺序是OnStepComplete先、OnComplete后。循环N次时OnStepComplete触发N次，OnComplete依旧只触发一次。还有一个细节是循环模式，Yoyo模式下第1次循环正向、第2次循环反向，OnStepComplete同样会在每次折返时触发，这个触发时机不是等折返动作完成，而是折返点也就是一循环的终点。

延迟和循环叠加在一起时，逻辑会变成这样：先走完延迟，再跑循环。假设SetDelay(1f)加SetLoops(2)，时间线是第0到1秒没有任何回调，第1秒之后补间开始第一次循环，第一次循环结束触发OnStepComplete，第二次循环结束触发OnStepComplete加OnComplete。多花点时间在纸上画一条时间轴，比靠脑子判断可靠得多。

3. 外部操作如何改变回调触发节奏

3.1 Play、Pause、Rewind对回调的影响

在补间播放过程中，外部调用Pause()、Play()、Rewind()会立刻改变补间状态，并且同步触发对应回调。这里的触发时机是立即的，不是在下一帧，而是在你调用方法的当帧同步触发。

举例，Pause()的典型坑是：在OnUpdate里根据某个条件调用tween.Pause()，Pause会触发OnPause回调。如果你在OnPause回调里又去修改补间的状态，就要小心递归调用。我遇到过一次在OnPause里调用Kill，结果OnKill在OnPause的调用栈里同步触发，日志顺序看起来就是OnUpdate、OnPause、OnKill连续三条。

Rewind()的作用是把补间回退到起点，它和Play()配合可以重播动画。回调方面，Rewind会触发OnRewind，并且在回退完成后如果补间是暂停的，会触发OnPause。如果回退前补间正在播放，Rewind会让补间立刻回到起点，但不会自动暂停，之后会继续从起点正常播放。这种场景下OnRewind的触发时机是在回退动作完成的那个更新节点，而不是调用Rewind的瞬间，具体要看补间当前进度是否已经处于0。DOTween的Rewind如果进度已经为0，不会触发多余回调。

3.2 Complete、Kill、SetAutoKill对回调的影响

Complete()是个经常被误用的方法。它表示强制把补间进度拉到终点。调用Complete()时，如果补间还没有播放完，DOTween会立即推进到终点，然后触发OnComplete。这里要注意，Complete()不会触发OnStepComplete，因为它是直接跳到最后一步，不是逐步走完循环。如果补间设置了SetLoops(3)，你只跑了1个循环就调用Complete()，它会直接跳到最终状态并触发OnComplete，但不会把中间两个循环的OnStepComplete补发。

Kill()则是销毁补间，触发OnKill。补间被Kill后就不能再恢复，所有回调都不会再触发。这个时机很好理解，但坑在第1小节提到的自动销毁。DOTween默认autoKill为true，补间播放完毕会在OnComplete之后立刻执行Kill，所以OnComplete和OnKill是紧挨着的。如果你在OnKill里访问这个补间的引用来做清理，可能会发现它已经被标记为不可用，因此建议在回调里不要依赖补间对象本身持续存活。

SetAutoKill(false)则会让补间播放完毕后保留在Active状态，不被销毁。此时OnComplete正常触发，但OnKill不会触发，因为补间还活着。要考虑的是，不自动销毁会导致补间对象一直占用内存，如果大量创建不销毁的补间，内存会持续增长。我一般在需要复用补间或需要反复播放的地方才会用SetAutoKill(false)，用完手动Kill。

4. 实战场景拆解：时间缩放与嵌套补间

4.1 时间缩放与回调

DOTween默认受Unity的Time.timeScale影响，这一点直接关系到回调触发时机。当timeScale为0时，DOTween里的补间不会推进，OnUpdate、OnComplete都不会触发。这里有一个很多人踩过的坑：在游戏暂停界面上用了DOTween做UI动画，timeScale=0之后动画直接停住，回调全都不触发。解决方式是给DOTween设置不受时间缩放影响的更新方式，比如SetUpdate(true)配合UpdateType.UnscaledTime，这样补间在暂停状态下依然会用真实时间推进，回调也会正常触发。

反过来，把timeScale调大，比如做2倍速播放，补间进度会按缩放后的时间加速推进，OnUpdate触发频率不变，但每次推进的进度增量变大。也就是说OnUpdate依然是每帧触发，但整体动画更快走完，OnComplete会更快到来。这个加速并不会跳帧触发OnUpdate，它仍然是逐帧调用，只是进度变化量大。

但这里有一个特殊的点：DOTween在极端的帧率波动时，如果一帧内进度跳过了多个循环节点，它只会按当前进度触发对应的最终回调，不会把中间每个循环的OnStepComplete都补一次。比如一帧时间很长导致二段循环阶段被跳过了，可能只触发最后一次的OnStepComplete和OnComplete。

4.2 嵌套补间与回调顺序

嵌套补间是指一个补间的回调里再创建或启动另一个补间，这种场景在实际项目里非常常见，比如一个角色攻击动画完成后衔接硬直动画。嵌套补间的回调顺序有一个隐蔽的坑：在回调里创建新补间时，新补间不会立刻启动它的OnStart，而是等到下一帧DOTween更新时才会触发。也就是说，父补间的OnComplete之后，子补间的回调不会同步触发，中间至少隔一帧。

如果你的逻辑里对顺序有严格要求，比如必须父动画的OnComplete紧接子动画的OnStart，用DOTween的Sequence会更合适。Sequence本质上就是把多个补间按顺序排列，前一个补间结束时会自动开始下一个，而不是隔一帧。不过使用Sequence时回调也会有一些行为变化，下面我结合自己踩过的一个坑讲。

除了嵌套，还有一种常见场景是同一GameObject上多个补间同时播放。此时回调的触发顺序取决于各自补间的进度，不会按照创建顺序统一触发。比如一个补间A播放10秒，补间B播放1秒，B的OnComplete会先于A的OnComplete触发，这跟创建先后没有关系。如果有强先后依赖，建议用Sequence或在一个回调里管理另一个补间的启动。

5. 回调不触发、顺序反了的排查清单

5.1 高频问题与原因对照

实际项目中，回调不触发或者说顺序不对，往往不是DOTween坏了，而是某个参数改变了回调的触发前提。我把几个高频问题整理成了表格，遇到疑似问题可以先对照排查。

这张表覆盖了我遇到过的绝大多数问题。特别是OnComplete不触发，很多时候不是DOTween的问题，而是补间压根没跑完。如果你的补间是无限循环你SetLoops(-1)，那OnComplete永远都不会触发，因为补间没有终点。

5.2 我的排查流程

遇到回调时序不对，我一般按固定流程排查。第一步先确认补间对象本身的状态，用tween.IsActive()和tween.IsPlaying()打印出来，看它到底是不是处于播放中。第二步检查参数，尤其是SetLoops、SetDelay、SetAutoKill这几个会改变触发前提的参数。第三步在回调里加标识日志，比如"OnStart_tick1""OnUpdate_tick45"这样的累计打印，连续跑几帧，把日志按顺序列出来。日志会告诉你真正的触发时刻，而不是你想当然的触发时刻。

如果排查到这一步还找不到原因，就把补间的创建代码单独抽到一个临时方法里，去掉所有外部调用，用最简单的链式结构跑一遍。我记得有一次排查了半天找不到问题，后来发现是另一个模块的全局TimeScale被改成0了，与补间本身无关。这种跨模块的全局状态往往是最难定位的。

6. 进阶技巧：用回调做状态机与事件解耦

6.1 用回调实现多阶段动画状态机

DOTween的回调非常适合实现轻量级动画状态机。以一个模拟项目X的三连击动画为例，第一个补间控制攻击位移，OnComplete触发第二个攻击补间，第二个OnComplete触发第三个，每个回调对应的状态清晰且可读。这种写法比在Update里集中判断状态要直观得多。

多阶段状态机的核心是把动画的不同阶段用回调串联起来，而不是在一个Update循环里用大量if判断。比如做一个面板弹出动画，可以拆成三个补间：位移进入、缩放回弹、透明度稳定，每个补间都用OnComplete驱动下一个阶段。阶段之间还可以通过Sequence组织，回调就是状态机里的状态转移信号，而DOTween的补间对象就是状态本身。

不过用回调做状态机有一个注意事项：当状态机被外部中断时，比如玩家再次点击面板导致动画重播，旧补间必须Kill掉并清理回调，否则旧补间的OnComplete可能会在下一次触发时误启动已经被替换的后继补间。我习惯在每次创建新动画前调用Kill，同时在OnKill里加一个是否需要重置状态的标记。

6.2 回调与对象池、异步流程的配合

对象池和DOTween回调也是常见的组合。比如子弹飞行的补间结束后，回调里执行回收子弹进池子。这里最怕的是对象已经被池子回收，补间却还在运行或者回调被延迟触发。解决方式是在回收前调用Kill，彻底断开生命周期。我之前做的一个物体飞行Demo里就处理过这个问题：子弹到达目标位置后，补间自动触发OnComplete，这时再执行回收，补间已经被autoKill掉，非常干净。

异步流程配合上，DOTween提供了ToTask()和异步等待方法，可以把回调包装成可等待的任务，用async/await顺序执行。比如等待一个UI动画完成后再执行加载逻辑，代码可以写成：

await transform.DOMove(new Vector3(0, 0, 0), 1f).AsyncWaitForCompletion();

这种写法的好处是把回调嵌套扁平化，OnComplete里的逻辑可以直接放在await之后，回调只作为底层信号。需要注意，AsyncWaitForCompletion受autoKill影响，如果补间被自动Kill，等待会自动完成，这一点我在实际项目里吃过亏，建议在需要的场景使用SetAutoKill(false)配合手动Kill。

最后再分享一个个人习惯：我在用DOTween写动画前，一定会先在纸上把回调时序画一条时间轴。DOTween的API已经做得非常简洁了，但简洁不等于简单，回调触发时机就是它内部最严格的那层逻辑。把OnStart、OnUpdate、OnComplete、OnStepComplete、OnKill这五个关键节点的时间点画清楚，后面真正写逻辑的时候几乎不会踩坑。时间轴上的每个标记旁边我会顺手写上会产生哪些外部操作，比如"此处可能调用Kill"，这样排查起来一目了然。这个小习惯帮我省下了很多调试时间，也推荐你试试。