企业官网建设流程全解析

DOTween 性能优化这件事，很多团队都是在项目跑起来、战斗特效堆到屏幕上、帧率从 60 掉到 30 的那天才开始认真对待的。我见过不少项目，前期用 DOTween 写动画写得非常顺手——一行transform.DOMove()就搞定，代码干净、开发效率极高，然后到了中后期，一个列表界面滚动一下、十几个元素同时做位移动画，主线程就冒出一片黄色的耗时块，GC 每隔几秒跳一次，帧率曲线开始出现规律的抖动尖峰。这时的第一反应往往是“DOTween 性能不行”，但实际把 Profiler 打开、把调用栈展开看，会发现大部分开销根本不在补间计算本身，而在我们自己的调用方式上：每帧创建 Tween、闭包回调漫天飞、UI 元素动画引发的 Canvas 重建、Kill 用错导致对象一直挂在活跃列表里。这篇就把我从多个实际项目里踩出来的经验拆开讲，从 DOTween 每帧到底干了什么开始，到更新模式选择、对象池与容量预分配、Sequence 的正确用法、UI 场景的真实瓶颈，最后给一份可以直接拿去自查的清单。适合已经能熟练写 DOTween、但被性能问题卡住的开发者看，也适合准备在项目里大规模使用补间动画、想提前避坑的人。

1. 先看清 DOTween 每一帧到底在做什么

1.1 一个 Tween 从创建到销毁的完整路径

想优化，得先知道它的工作模型。DOTween 的核心设计非常朴素：你调用transform.DOMove(...)时，它内部会从对象池里取一个TweenerCore实例，把你的目标对象、起始值、结束值、时长、缓动曲线、回调全部塞进去，然后把这个实例注册到一个全局的活跃 Tween 列表里。之后，每到 DOTween 的更新时机（默认是 Unity 的Update），它会遍历这个活跃列表，对每一个 Tween 计算当前进度，调用缓动函数把线性进度t映射成缓动后的t'，再通过一个 setter 委托把插值结果写回你的目标属性。Tween 结束时，如果没有被标记为可回收，它会被销毁并从列表里移除；如果标记了可回收，它会回到池子里等着下次复用。

这条路径上有三个明确的成本点：创建时的分配（对象本身、委托、可能还有闭包）、每帧的遍历与计算（列表遍历 + 缓动采样 + setter 调用）、结束时的清理（列表移除、事件触发、可能的 GC）。大部分优化工作，本质上就是把这三块成本压下去，或者把它们从“每帧发生”变成“一次性发生”。

我在一个中大型项目里做过一次统计：某个战斗场景里同时存活的 Tween 大约在 300 到 500 个之间波动，其中真正需要每帧更新的属性动画只占六成左右，剩下四成里有一半是已经播完但因为没有开启自动销毁而残留在列表里的“僵尸 Tween”，还有一部分是重复创建、逻辑上互相覆盖的动画。光是清理掉这批残留，主线程的 Tween 更新耗时就直接降了将近四成。这个数字说明一件事：优化 DOTween 的第一步不是调参数，而是搞清楚你的活跃列表里到底有多少东西是必须存在的。

1.2 真正的开销大头：托管分配、调度遍历与属性写入

把开销拆细一点，DOTween 的性能成本主要分布在以下三个层面，影响量级从大到小排列大致如下：

第一项是最容易被忽视的。很多人写动画时习惯这样写：

void Update() { if (Input.GetKeyDown(KeyCode.Space)) { transform.DOScale(Vector3.one * 1.2f, 0.2f) .SetLoops(1, LoopType.Yoyo) .OnComplete(() => { /* 这里捕获了外部变量 */ }); } }

这段代码本身形式没错，但如果OnComplete里的 Lambda 捕获了外部局部变量，编译器会为它生成一个闭包类，每次执行都会产生一次堆分配。如果这个动画是在列表项里、被滚动触发、一秒钟触发几十次，那 GC 压力就很可观了。更糟的是在Update里无条件调用的写法——那基本上等于每帧都在堆上扔垃圾。

第二项的关键在于活跃列表的长度控制。DOTween 的遍历是线性的，一个 Tween 哪怕已经处于暂停状态或者延时还没到，只要它还在列表里，每帧都要被访问一次。所以延时很久的动画、暂停的动画、播完没销毁的动画，都是纯粹的负担。

第三项是被低估得最厉害的。补间计算本身其实很便宜——一次 Vector3 插值加一次属性赋值，纳秒级。但如果这个属性是RectTransform.anchoredPosition，赋值会触发 UGUI 的布局与网格重建流程，那个成本是补间计算的几十倍甚至上百倍。也就是说，你以为在优化 DOTween，实际上要优化的是它触碰的那些属性。

1.3 用 Profiler 把“感觉卡”变成“知道卡在哪”

优化必须从测量开始，否则全是猜。我常用的定位流程是这样的：

1. 在 Unity Profiler 里打开 CPU Usage，把视图切到 Hierarchy，展开Update.ScriptRunBehaviourUpdate。
2. 搜索DOTween，看DOTween.Update或DOTween.ManualUpdate这一项的 Self ms 占比。
3. 如果这一项不高（比如只占 0.3ms），但整体还是卡，那问题几乎肯定不在补间计算，而在它触发的下游——继续往下看Canvas.SendWillRenderCanvases、CanvasUpdateRegistry、Graphic.Rebuild这些项。
4. 如果这一项很高，那就要看活跃 Tween 数量：在运行时打印DOTween.TotalPlayingTweens()和DOTween.TotalActiveTweens()，两者差值就是“挂着但没在播”的数量。

这两个静态方法非常实用。我一般在调试面板上放了两个实时数字，一个是活跃总数，一个是正在播放数。正常情况下这两个数字应该接近，如果活跃数长期是播放数的两三倍，说明代码里有大量 Tween 创建后没有被正确回收，那就是最优先要处理的问题。

提醒：TotalActiveTweens包含暂停和延时中的 Tween，TotalPlayingTweens只统计真正在推进的。两个数字长期背离，是内存泄漏型 Tween 的典型信号。

2. 更新时机选错，后面的优化都是白费

2.1 四种更新时机的实际差异

DOTween 支持把 Tween 挂到不同的更新时机上，默认是UpdateType.Normal，也就是跟着 Unity 的Update走。其他三个选项是LateUpdate、FixedUpdate和手动更新。这个选择看起来只是个小开关，实际影响却不小。

UpdateType.Normal的问题在于它和你的游戏逻辑、输入处理挤在同一帧的同一个阶段。如果 Tween 的目标是相机或者跟随目标，用 Normal 会出现“相机先动、物体后动”的一帧延迟抖动，这时应该用LateUpdate。而FixedUpdate用于物理相关的补间，比如给刚体做位置插值，用 Normal 会导致物理步进和渲染帧不同步，出现视觉上的抖动。

真正需要留意的是FixedUpdate的隐藏成本：DOTween 在 Fixed 模式下会在每次物理步进时推进 Tween，而物理步进频率（默认 50Hz）通常低于渲染帧率。如果你的游戏跑在 60 帧甚至更高，用 Fixed 模式的 Tween 实际上是“每帧不一定更新”，反而节省了一点计算，但也带来了视觉上的不连贯。所以选择原则很简单：视觉相关的动画用 Normal 或 Late，物理相关的用 Fixed，不要为了省一点点计算把所有东西都塞进 Fixed。

2.2 手动驱动 DOTween 的适用边界

DOTween 提供DOTween.ManualUpdate(deltaTime, unscaledDeltaTime)，配合在DOTween.Init时关闭自动更新，可以让你完全掌控推进时机。这个能力在两种场景下特别有价值：

第一种是需要精确控制动画时间流速的场景，比如战斗中的子弹时间、UI 的全局减速效果。手动驱动可以让你传入一个自己算好的 deltaTime，做出各种时间扭曲效果，而不必去动Time.timeScale（动 timeScale 会牵连物理、音频、粒子等一大堆系统）。

第二种是需要把动画更新从主循环里挪出去的场景，比如你想在某个特定阶段（加载完、渲染前）统一推进一次，避免和其他系统交错。

但手动驱动也有明显的坑：一旦开了手动模式，所有Tween 都不再自动推进，包括那些你以为会自己跑的 UI 动画。我见过有项目为了做一个子弹时间效果开了手动模式，结果整个游戏的 UI 动画全部静止，排查了半天才发现是这个原因。所以如果只是局部需要控制时间流速，更稳妥的做法是用SetUpdate单独指定，而不是全局切成手动。

// 只让某个 Tween 使用独立时间，不受 timeScale 影响 transform.DOMove(target, 0.5f) .SetUpdate(UpdateType.Normal, isIndependentUpdate: true);

2.3 timeScale 相关的一连串隐式问题

SetUpdate(true)让 Tween 忽略Time.timeScale，这在暂停菜单、过场动画里很常用。但要注意，忽略 timeScale 之后，Tween 的时长是按真实时间算的，如果游戏本身在做慢动作，这类 Tween 会显得“跑得飞快”。

更麻烦的是暂停恢复时的状态错乱。很多项目在打开背包界面时会把Time.timeScale设为 0，然后发现某些 Tween 卡在半路，恢复之后又从半路继续。这本身是预期行为，但如果这个 Tween 是在循环播放的，恢复的瞬间可能会跳到一个奇怪的位置。我的处理习惯是：所有与 UI 相关的 Tween 统一用独立时间，所有与游戏世界相关的用默认时间，两套体系泾渭分明，不要混用。这样暂停和恢复的语义就非常清晰，排查问题也容易。

还有一点容易被忽略：DOTween.KillAll()在某些实现里会受 timeScale 影响吗？不会，Kill 是立即生效的。但DOTween.PauseAll()和DOTween.PlayAll()是全局操作，如果你的项目里有多个独立模块各自管理自己的动画，全局暂停很容易误伤——比如你在暂停游戏世界的时候顺手 PauseAll，把 UI 的动画也一起冻住了，界面上就会出现按钮不动的怪现象。所以我的建议是永远不要用全局的 PauseAll/PlayAll/KillAll，一律用DOTween.Kill(target)按目标精确操作。

3. 把分配压下去：容量预分配与对象池的正确姿势

3.1 Init 和 SetTweensCapacity 到底在分配什么

DOTween 内部维护两个池子：Tweener 池和 Sequence 池。初始化时它会预分配一定容量的数组来存放这些对象，如果你的活跃数量超过容量，它会动态扩容——而扩容意味着一次数组拷贝和新的堆分配，这会在运行时造成突发性的 GC 压力。

默认容量是比较保守的，对于 UI 元素多、特效密的项目，很容易被撑爆。我一般会在游戏启动的最开始（第一个场景加载前）显式设置容量：

// 参数依次为：Tweener 容量、Sequence 容量 DOTween.SetTweensCapacity(800, 100);

这两个数字怎么定？用实测。在战斗最激烈的场景里跑一遍，打印DOTween.TotalActiveTweens()的峰值，再乘个 1.5 的余量就是合适值。设太小会频繁扩容，设太大会浪费内存——每个 Tweener 对象不小，800 个和 3000 个的内存差距是能感觉到的。我通常在 500 到 1000 之间取值，配合下面要说的回收策略，基本不会碰到扩容。

初始化调用必须早于任何 Tween 的创建。如果忘了这一点，DOTween 会用默认参数自己初始化一次，之后你再调容量设置就无效了。所以把这段代码放在一个带[RuntimeInitializeOnLoadMethod]的静态方法里，或者游戏的启动引导里，是最稳妥的。

3.2 SetRecyclable 与 SetAutoKill 的组合策略

这两个 API 名字很像，作用完全不同，混淆它们是最常见的错误来源。

SetAutoKill(true)（默认）表示 Tween 在播放完成后自动销毁。这对一次性的动画是合理的，但如果你的动画需要反复播放（比如按钮的呼吸效果、列表项的入场动画），每次重建都会产生分配。

SetRecyclable(true)表示 Tween 在结束后回到池子里等待复用，而不是被彻底销毁。配合SetAutoKill(false)，你可以得到一个可反复Restart()的 Tween 实例。

正确的组合方式我总结成这张表：

全局设置可以这样：

DOTween.Init(recycleAllByDefault: true, useSafeMode: true, logBehaviour: LogBehaviour.ErrorsOnly);

useSafeMode建议只在开发期开启。它会在每个 Tween 更新时检查目标对象是否已被销毁，避免访问空引用报错，但代价是每帧多了一次判空。正式包一定要关掉，否则等于给每个 Tween 都加了一层额外开销。这个坑我在早期项目里踩过——全局开了 SafeMode，几百个 Tween 同时跑，光是判空就吃掉了一截帧时间。

3.3 Kill 和 Complete 的语义区别，以及正确的调用点

DOTween.Kill(target)和DOTween.Complete(target)的差别在于：Kill 是“中断并清理”，Complete 是“立即跳到终点并触发完成回调”。选错会导致很微妙的 bug——比如你用一个 Tween 来驱动血条的缩放，玩家死亡时想立刻把血条归零，如果用 Kill，血条会停在半路；如果用 Complete，会瞬间走完动画。这两种行为在不同场景下都是对的，关键是你要清楚自己要哪个。

更重要的是调用时机。我见过最典型的问题是在OnDestroy里忘了 Kill：

void OnDestroy() { // 必须写，否则目标销毁后 Tween 仍在活跃列表里跑 transform.DOKill(); }

如果没有这行，目标对象被 Destroy 之后，Tween 依然在活跃列表中，每帧都会尝试往一个已经销毁的 Transform 上写值。开了 SafeMode 的话不报错但白跑，没开的话直接空引用。UI 列表项反复创建销毁时，这个问题会迅速累积成几十上百个僵尸 Tween。

另外transform.DOKill()只会 Kill 挂在这个 Transform 上的直接 Tween。如果 Transform 的子物体上也有 Tween，父物体销毁时子物体的 Tween 不会自动清理。这种情况要么在销毁时递归清理，要么用SetLink：

// 绑定到 GameObject 生命周期，对象销毁时 Tween 自动清理 transform.DOMove(target, 0.5f).SetLink(gameObject);

SetLink是解决这类问题的标准手段，尤其是 UI 元素，加上它之后基本不用再操心清理问题。唯一要注意的是它内部会挂一个监听组件，数量极大时（几百个）会有少量额外开销，但相比僵尸 Tween 的代价，这个开销完全可以接受。

4. Sequence 用得好是省事，用错了是拖累

4.1 Append 和 Join 背后是一次结构构建

Sequence 的优势是把多个 Tween 编排成时间轴，代码可读性极强。但它的构建过程本身是有成本的：每次Append或Join都会触发内部时间轴的重新计算和嵌套结构的组织。如果你在运行时高频创建一个包含十几个子 Tween 的 Sequence，这个构建开销会累积得很明显。

我的经验是：结构固定的 Sequence 一定要缓存起来复用。

Sequence _uiOpenSeq; void Awake() { _uiOpenSeq = DOTween.Sequence() .SetAutoKill(false) .Append(panel.DOScale(Vector3.one, 0.25f).From(Vector3.one * 0.8f).SetEase(Ease.OutBack)) .Join(canvasGroup.DOFade(1f, 0.2f)) .AppendInterval(0.05f) .Append(title.DOLocalMoveY(0, 0.2f).From(50f)); } void Open() => _uiOpenSeq.Restart(); void Close() => _uiOpenSeq.Rewind();

这样只构建一次，之后全靠Restart/Rewind推进。注意Rewind会把所有子 Tween 回退到初始状态，Restart则是从头播放。这样写还能保证每次打开动画的节奏完全一致，不会因为构建顺序有细微差异导致表现不统一。

4.2 什么时候该把大量小 Tween 合并

一个常见场景：列表里有 20 个元素，每个都要做入场动画，延迟递增。直觉写法是循环 20 次，每次创建一个 Tween 加上不同的 delay。这样会产生 20 个独立 Tween，每个都要在活跃列表里被单独遍历。

更省的做法有两种。第一种是把整个列表当成一个整体，用一个 Sequence 加不同的 Insert 时间点：

var seq = DOTween.Sequence(); for (int i = 0; i < items.Count; i++) { seq.Insert(i * 0.03f, items[i].DOFade(1f, 0.2f)); }

这样只有一个 Sequence 在活跃列表里，遍历成本集中在一处。

第二种做法适合更极端的情况——如果你有一大堆相同类型的属性动画（比如 50 个图标同时做缩放），可以用一个统一的驱动源手动计算，完全绕开 DOTween：

float _t; void Update() { _t += Time.deltaTime / 0.3f; float k = Mathf.Clamp01(_t); float v = 1f + 0.2f * Mathf.Sin(k * Mathf.PI); // 替代缓动曲线 for (int i = 0; i < icons.Length; i++) icons[i].localScale = Vector3.one * v; }

这段代码看起来“土”，但在这个特定场景下比 50 个 Tween 快得多，因为它只有一次遍历、零分配。我的判断标准是：当同类动画数量超过 20 个、且目标属性简单（纯数值或纯 Vector3）时，手动批量驱动通常更快。数量少的时候用 DOTween 更省心，没必要提前优化。

4.3 嵌套 Sequence 与回调链的代价

Sequence 支持嵌套，一个 Sequence 里可以 Append 另一个 Sequence。这在组织结构上很方便，但嵌套层级过深会带来两个问题：一是调试时难以追踪是哪一层出了问题，二是内层 Sequence 的完成回调触发时机可能不符合直觉。

我的习惯是嵌套不超过两层。三层以上的序列结构，我宁愿把它拆成几个独立的 Sequence，用OnComplete串联，或者干脆用一个状态机管理阶段。因为深度嵌套的 Sequence 在修改时极其脆弱——你想调中间某一段的时长，往往牵动整体时间轴的重新计算。

回调链也是同理。.OnComplete(() => { ... }).OnComplete(() => { ... })这种写法，每加一个回调就多一次委托分配。如果回调里还有闭包捕获，分配量更大。对于频繁创建的场景，可以用方法组代替 Lambda：

// 有分配 tween.OnComplete(() => OnAnimDone(item)); // 无闭包分配（前提是不需要捕获循环变量） tween.OnComplete(OnAnimDone);

注意如果OnAnimDone需要参数，就不能这样简写，得用字段或者给 Tween 加 Id 再在回调里查。这个改写看起来琐碎，但在高频路径上确实能减少 GC 频率。

5. UI 动画的性能大头往往不在 DOTween 身上

5.1 RectTransform 动画如何触发 Canvas 重建

这是我认为最值得单独讲的一块。DOTween 对RectTransform.anchoredPosition做插值，一帧写一次值。写值本身很便宜，但 UGUI 监听到 RectTransform 变化后，会把这个元素标记为需要重建，然后在帧末的Canvas.SendWillRenderCanvases阶段重新生成网格。如果这个元素所在的 Canvas 下还有大量其他元素，整个 Canvas 的批次都可能需要重新合并。

也就是说，一个元素的位移动画，可能连带整个 Canvas 下几百个元素一起重建。这在 UI 复杂的界面里是灾难级的。

解决方法是拆分 Canvas。把所有需要频繁动画的元素放到独立的子 Canvas 下：

// 给需要独立动画的容器加上 Canvas 组件 var subCanvas = animatedRoot.AddComponent<Canvas>(); subCanvas.overrideSorting = false;

子 Canvas 的重建范围被限制在它自己内部，不会波及父级。我实测过一个背包界面，把所有物品格子的动画容器拆成独立 Canvas 之后，Canvas.SendWillRenderCanvases的耗时从每帧 2ms 以上降到 0.3ms 左右，收益比调十次 DOTween 参数都大。

另外要提醒的是，只要元素在做位移动画，就不要把它放在带 LayoutGroup 的容器里。LayoutGroup 会在每次子元素尺寸变化时重新计算布局，而布局计算的开销远高于动画本身。要么把动画元素移出 LayoutGroup，要么在动画期间禁用 LayoutGroup 组件，动画结束后再启用。

5.2 数字滚动与颜色渐变的真实成本

数字滚动是另一个典型陷阱。用一个DOTween.To去驱动 Text 的文本内容，每帧都设置一次 string，每次设置都会触发文本组件的重新生成顶点和网格。一个三位数的滚动，一秒钟就是几十次网格重建。

我的处理方式是分档：

• 一两位的小数字（金币、等级），直接改文本可以接受，但要用缓存好的字符串，避免每帧ToString产生的分配。
• 三四位以上的大数字，改用图集数字（把 0-9 做成图片，只改每位的 Sprite 或者位置），这样只涉及 Sprite 切换，成本极低。
• 更极端的场景（比如伤害数字飞速跳动），可以只更新显示的位数变化，或者用固定的占位符加位移动画做视觉欺骗。

颜色渐变的成本比想象中低。UGUI 里修改Graphic.color会改变顶点色，但不会改变顶点位置，重建范围相对可控。不过如果同时有大量元素在做颜色渐变，累积起来也不容忽视。我的做法是尽量用 CanvasGroup 的 alpha 做整体淡入淡出，这比逐个改元素颜色高效得多——CanvasGroup 的 alpha 是在渲染阶段生效的，不触发网格重建。

5.3 与 Mask、LayoutGroup 共存时的注意事项

带 Mask 或者 RectMask2D 的容器，子元素的网格重建成本会更高，因为需要额外做裁剪计算。如果一个容器同时具备“有 Mask”、“有 LayoutGroup”、“子元素在播放位移动画”这三个条件，性能基本就废了。

我在项目里定的规则是：动画元素永远放在最底层的叶子节点，不参与布局计算，不被 Mask 裁剪。如果界面设计要求必须在遮罩内做动画，那就把遮罩区域做成独立的子 Canvas，并且确保遮罩的尺寸在动画期间不变。这样至少能保证裁剪计算只做一次。

还有一个小技巧：对于淡入淡出类的动画，如果元素本身没有交互需求，可以在动画期间把它从 Canvas 的渲染批次里彻底摘出去（设置enabled = false或者移出可见区域），动画开始前再挂回来。这个做法比较极端，但对付那种一次性的大面积转场动画很有效。

6. 高频误用清单与可直接复用的改法

6.1 每帧创建 Tween 的几种变体写法

除了明显的Update里创建，还有几种隐蔽变体：

// 变体一：属性 setter 里创建 public float Value { set { _label.DOText(value.ToString(), 0.2f); } // 每帧设置就每帧新建 Tween } // 变体二：滑动条回调里创建 slider.onValueChanged.AddListener(v => icon.DOScale(v, 0.1f));

第一种的正确做法是维护一个持久 Tween，用ChangeEndValue更新终点：

Tween _valueTween; public void SetValue(float v, bool instant = false) { if (_valueTween == null || !_valueTween.IsActive()) _valueTween = _label.DOText(v.ToString("0"), 0.2f); else if (instant) _valueTween.Complete(); else _valueTween.ChangeEndValue(v.ToString("0"), true); }

ChangeEndValue的第二个参数表示是否平滑过渡到新目标，这个 API 是专门为“目标值频繁变化”的场景设计的，用它可以完全避免重复创建。

6.2 缓动曲线选择的取舍

内置的缓动函数（Ease.OutQuad 等）是纯数学计算，成本极低。但用SetEase(AnimationCurve)传入自定义曲线时，每次采样会走曲线求值流程，成本明显更高——在几百个 Tween 同时跑的场景下，这个差异能看出来。

如果确实需要自定义曲线，把 AnimationCurve 实例缓存成字段，不要每次动画都新建一个。另外曲线的关键帧数量也影响采样速度，十来个关键帧和上百个关键帧不是一个量级，能用少量关键帧表达的效果就不要堆关键帧。

6.3 一份可以照着做的自检清单

我在每个项目的中后期都会跑一遍下面这套检查，基本能覆盖八成的性能问题：

1. 打开调试面板，实时显示TotalActiveTweens和TotalPlayingTweens，观察两者比值是否长期大于 1.5。
2. 在 Profiler 里确认DOTween.Update的 Self ms，如果超过 0.5ms 就要查活跃数量。
3. 检查所有OnDestroy是否都调用了DOKill或者 Tween 是否加了SetLink。
4. 搜索代码里所有.DO开头的方法调用，确认没有位于Update、属性 setter、事件回调高频触发的位置。
5. 检查所有循环播放的动画是否用了SetAutoKill(false)+Restart，而不是每次重建。
6. 检查 UI 动画元素是否在独立 Canvas 下，是否在 LayoutGroup 内部。
7. 确认正式包已经关闭useSafeMode。
8. 跑一次长时间的自动战斗或者界面反复开关，看 GC Alloc 曲线是否平稳。

第 4 条最容易被忽视，因为代码扫描不看运行时上下文。我一般会写个简单的静态检查脚本，把.DO调用位置的文件名行号打印出来，人工过一遍，效率比盲猜高得多。

还有一条经验：不要在性能优化还没做完的时候就去上更复杂的方案。我见过有团队一开始就想着自己写一套补间系统替换 DOTween，结果花了两个月，最后发现原来的问题只是几个忘记 Kill 的 Tween 加上一个没拆分的 Canvas。先用 Profiler 把问题定位清楚，再决定要不要动架构，这个顺序不能反。

最后分享一个我在多个项目里反复验证过的小习惯：给所有动画写一个统一入口，比如TweenHelper.PlayScale(Transform target, float scale, float duration)，内部统一处理DOKill旧动画、设置更新模式、挂SetLink、开启回收这一系列动作。团队成员写动画时只调这个入口，不直接碰 DOTween 的链式 API。这么做的好处是，哪天需要整体调整回收策略或者统一加埋点，只改一处就行，不用满项目搜索.DO。前期多花半天封装，后期能省下大量的排查时间。