WPF 页面切换特效：可复用动画工厂与导航打断实践

简介：这份资源面向具备一定 C# 基础的 WPF 桌面开发学习者，聚焦界面切换特效这一常见但不易做好的交互环节，帮助解决页面导航生硬、过渡动画难以协调、控件状态外观切换混乱等问题。压缩包共 47 个文件、约 145KB，以 15 个 cs 代码文件为核心，配合 4 个 xaml 与 3 个 baml 界面定义文件、sln 与 csproj 工程文件，以及编译产物 exe、dll、pdb 与 resources 等，构成一个可直接打开运行的 WpfApplication1 示例工程，另有少量 txt、resx、manifest 配置项。资源围绕 Frame 与 NavigationWindow 导航、补间与关键帧动画、Storyboard 多动画编排、TranslateTransform 等变换应用、VisualStateManager 状态管理展开，示例以双页面左右平移滑动切换演示动画时序的匹配方式。已有 1482 人学习，适合对照代码理解特效的实现路径，并迁移到自己的项目中打磨过渡细节。

1. 一个切页面像刷新网页的后台系统，让我把 WPF 界面切换特效重做了一遍

某公司内部工单后台的左侧树形菜单点一下，右侧内容“啪”地整块换掉，用户反馈说“看着卡”——其实数据早就回来了，缺的只是画面过渡。后来我把这套 WPF 界面切换特效整理成一个可复用的切换模块，纯 C# 加 XAML 实现，不引第三方 UI 库：淡入淡出、左右滑入、缩放淡入、立方翻转四种基础特效，时长、缓动、位移比例全部走配置，业务页面一行动画代码都不用写。它适合两类人：手上一堆 XAML 页面、却找不到统一动画入口的 WPF/C# 开发者；以及想把老后台视觉质感抬一档、又不想动业务逻辑的人。

2. 整体架构：宿主控件、动画工厂、导航服务三层拆开

拿到一份特效资源，最容易犯的错是直接打开某个页面看它怎么写 Storyboard，然后复制粘贴到自己的页面里。单页能跑，二十个页面就会变成二十份不一致的动画代码，改一个曲线要翻二十个文件。所以我第一件事是把结构拉平：宿主控件负责“什么时候切”，动画工厂负责“怎么动”，导航服务负责“切到哪、能不能打断”。三件事分开，后面加特效才有地方下手。

2.1 目录结构与模块职责

资源包解压之后的目录，大致是这样一套分层，我在自己项目里也沿用了同样的划分：

WpfTransitions/ ├─ Controls/ │ ├─ TransitioningContentControl.cs 宿主控件：旧页/新页两层叠加，触发动画 │ └─ TransitioningContentControl.xaml 默认模板，两个 ContentPresenter + ClipToBounds ├─ Transitions/ │ ├─ TransitionKind.cs 枚举：None/Fade/SlideLeft/SlideRight/ZoomFade/CubeFlip │ ├─ EaseFactory.cs 缓动工厂，统一进出场手感 │ ├─ TransitionFactory.cs 按枚举造 Storyboard，唯一的动画出口 │ └─ TransitionPresets.cs 时长、位移比例等可调参数集中在这里 ├─ Navigation/ │ ├─ INavigationService.cs 导航契约：Navigate / GoBack / CanGoBack │ ├─ NavigationService.cs 导航栈 + 切换状态机 + 请求队列 │ └─ NavigationRequest.cs 一次切换的请求对象（视图、特效、方向） ├─ Themes/ │ └─ Generic.xaml 控件默认样式，合进 App.xaml 的 MergedDictionaries └─ Demo/ ├─ MainWindow.xaml 菜单 + 宿主控件的演示壳 └─ Views/ 若干 Demo 页面，纯业务内容，无动画

这个划分的关键点在于：Transitions目录是整个包里唯一 new 出Storyboard的地方。业务页面只暴露一个 UserControl，导航服务调用SwitchTo(view, TransitionKind.SlideLeft)，页面本身对动画完全无感知。以后觉得滑入太慢，改TransitionPresets里的一个常量，全站生效——这是这套结构最值钱的地方，比特效本身好看更重要。

Controls目录承担的是视觉承载。宿主控件把旧内容暂存到OldContent依赖属性上，模板里用两个ContentPresenter上下叠着放，外层Grid开ClipToBounds="True"防止滑动时内容溢出到窗口外。这个细节不做，滑入动画会看到页面从标题栏外面飞进来，非常出戏。

2.2 三条实现路线的取舍：Storyboard、VisualStateManager、第三方切换控件

WPF 里做页面切换，实际可走的路不止一条，资源包里最终选了手写 Storyboard 这条路，理由是三条路线我都试过，各有各的适用区间：

VisualStateManager 那条路最容易被误导。很多人看到“状态”两个字就往里套，结果发现页面切换要的是“旧页退场动画跑完，新页再入场”，而 VSM 的一次GoToState只会选中一个状态里的 Storyboard 一起跑，做交叉淡入可以，做严格的串行时序就得拆成两个状态反复切，状态一多就失控。我的判断标准很简单：动画之间需要先后依赖、需要中途打断、需要按运行时尺寸算距离的，一律手写 Storyboard；纯粹是鼠标悬停、按下这类互斥视觉反馈，才交给 VisualStateManager。

第三方控件包的问题在二次开发阶段才暴露。某个特效你不满意，想把它从 300ms 改成 200ms 并且位移减半，翻进源码发现时长是硬编码在 XAML 里的，还没暴露成依赖属性，只能整段复制出来改。资源包这种自己掌控动画工厂的做法，代价是前期多写两百行，收益是后面每一次调整都在自己手上。项目里如果只是三五个页面的小工具，用第三方控件完全够；一旦是几十个页面的后台系统、还要统一视觉规范，自己搭这一层更省事。

还有一条路是 .NET 8 之后 WPF 引入的合成层 API，能把动画交给渲染线程。它在持续高帧率动效上有优势，但对“页面切换”这种短时、事件驱动的场景收益有限，而且引入新 API 会让整个项目的目标框架被绑死。资源包没有走这条路，我觉得是稳妥的取舍。

3. 核心动画拆解：一次页面切换在 XAML 和 C# 里到底跑了什么

特效好不好看，八成取决于两个东西：动的是哪些属性，以及时间曲线怎么走。这一章把一次切换的完整链路摊开，从模板里的两个 ContentPresenter 开始，到最终 Storyboard 提交给 WPF 动画系统，中间每一步都能对应到具体代码。

3.1 从旧页退场到新页入场的完整链路

先看宿主控件的模板。两个 ContentPresenter 上下叠放，旧页在下、新页在上，动画只动新页的位移和透明度，旧页做反向的小幅位移加淡出，形成视差：

<!-- Themes/Generic.xaml：宿主控件默认模板 --> <Style TargetType="{x:Type ctl:TransitioningContentControl}"> <Setter Property="Template"> <Setter.Value> <ControlTemplate TargetType="{x:Type ctl:TransitioningContentControl}"> <!-- ClipToBounds 必须开，否则滑动时内容会飞出宿主边界 --> <Grid x:Name="PART_Root" ClipToBounds="True" Background="Transparent"> <!-- 旧页面：切换瞬间由代码把原 Content 搬进来 --> <ContentPresenter x:Name="PART_OldPresenter" Content="{TemplateBinding OldContent}" Visibility="Collapsed" /> <!-- 新页面：当前 Content，一直在最上层 --> <ContentPresenter x:Name="PART_NewPresenter" Content="{TemplateBinding Content}" /> </Grid> </ControlTemplate> </Setter.Value> </Setter> </Style>

然后是控件侧的切换入口。整个切换过程只有三个动作：把当前内容搬到旧层、把新内容塞进新层、造一个 Storyboard 跑起来。关键在于动画结束后的收尾——旧层要清空，变换要重置，否则第二次切换时位移会叠加：

// Controls/TransitioningContentControl.cs public void SwitchTo(object newContent, TransitionKind kind, TimeSpan? duration = null) { if (_newPresenter == null) { Content = newContent; return; } // 上一次动画没跑完就掐掉，避免两个 Storyboard 抢同一批属性 _board?.Stop(); OldContent = Content; // 当前页面降级为旧页 Content = newContent; // 新页面立刻进视觉树，参与布局 _oldPresenter.Visibility = OldContent == null ? Visibility.Collapsed : Visibility.Visible; _oldPresenter.Opacity = 1; EnsureTransform(_oldPresenter); EnsureTransform(_newPresenter); // 位移距离按宿主实际宽度取比例，DPI 缩放下也不会错位 double distance = ActualWidth * TransitionPresets.SlideRatio; _board = TransitionFactory.Create(kind, _oldPresenter, _newPresenter, distance, duration ?? TransitionPresets.DefaultDuration); if (_board == null) { OldContent = null; return; } // TransitionKind.None _board.Completed -= OnSwitchCompleted; _board.Completed += OnSwitchCompleted; _board.Begin(this, true); // true：允许 Storyboard 操作模板内部元素的属性 } private void OnSwitchCompleted(object sender, EventArgs e) { // 解绑必须写在最前面，否则 Storyboard 被事件委托钉住，永远回收不掉 ((Storyboard)sender).Completed -= OnSwitchCompleted; OldContent = null; _oldPresenter.Visibility = Visibility.Collapsed; ResetTransform(_newPresenter); // 清掉动画残留的变换值 _board = null; SwitchCompleted?.Invoke(this, EventArgs.Empty); }

Begin(this, true)那个true参数是整段代码里最容易漏的。它的含义是允许这个 Storyboard 控制模板内部子元素的属性，少了它，SetTarget指向模板里的 ContentPresenter 时动画完全不生效，也不报错——典型的黑匣子式失败。distance用ActualWidth乘比例而不是写死像素，是为了兼容 125%、150% 缩放：写死 200px 在 100% 缩放下刚好是半屏，到 150% 就变成了三分之一屏，滑入速度看起来会明显变快。

EnsureTransform里还有一步防御，业务页面自己可能已经设了RenderTransform做缩放，直接覆盖会把人家的效果吃掉，所以统一包进TransformGroup，约定 Translate 固定放在Children[1]位置：

private static void EnsureTransform(UIElement element) { if (element.RenderTransform is TransformGroup g && g.Children.Count >= 2) return; // 业务页面的 Scale/Rotate 保留在 [0]，Translate 固定占 [1]，属性路径才稳定 var group = new TransformGroup(); group.Children.Add(new ScaleTransform(1, 1)); group.Children.Add(new TranslateTransform()); element.RenderTransform = group; element.RenderTransformOrigin = new Point(0.5, 0.5); }

这样一来，动画里的属性路径就能写成固定形式RenderTransform.Children[1].(TranslateTransform.X)，不用每次去猜目标元素上挂的是哪种 Transform。这个约定在资源包里贯穿所有特效，加新特效时照着写就行。

3.2 缓动函数与位移比例：手感参数怎么定

属性路径定好之后，决定“看起来舒不舒服”的就是时间参数。默认的线性动画在 WPF 里几乎等于难看：匀速滑入像机械臂，匀速淡入像断电。资源包把缓动统一收进一个工厂类，所有特效都从这里取，保证全站手感一致：

// Transitions/EaseFactory.cs public static class EaseFactory { // 入场用 EaseOut：起步快、收尾慢，符合“东西被甩进来”的直觉 public static IEasingFunction Enter() => new CubicEase { EasingMode = EasingMode.EaseOut }; // 退场用 EaseIn：起步慢、加速离开，视觉上比匀速干脆 public static IEasingFunction Exit() => new QuadraticEase { EasingMode = EasingMode.EaseIn }; // 弹性收尾，只给需要“顿一下”的特效用，用多了整站会显得轻浮 public static IEasingFunction Back() => new BackEase { Amplitude = 0.25, EasingMode = EasingMode.EaseOut }; }

几个参数的实际取值经验：CubicEase的强度介于QuadraticEase（更缓）和QuarticEase（更陡）之间，日常页面切换用它基本不会翻车。BackEase的Amplitude控制回弹幅度，默认 1 太大，收尾会往回弹十几个像素，看着像手抖，调到 0.2 到 0.3 只是轻微“顿”一下。ElasticEase的Oscillates默认 3 次振荡，用在页面切换上就是灾难，我一般只在弹窗出现时用，还得把振荡压到 1 次。

时长和位移比例集中放在TransitionPresets，这是二次开发时改得最频繁的文件：

滑动类特效我固定让旧页只走新页三分之一的反向位移。这个 1/3 不是拍脑袋：如果两页同速反向移动，视觉上像两块板硬生生错开，纵深为零；如果旧页完全不动只淡出，又显得新页是在“贴”上去。三分之一的反向小位移加淡出，人眼会解读成旧页退到后面去了，页面之间有了空间关系。

还有一个容易被忽略的参数是动画的FillBehavior。默认值是HoldEnd，动画结束后属性值会被“钉”在终值上，页面位移停在To位置不再恢复。对一次性动画来说这往往是错的：后续布局变化、窗口缩放再触发RenderTransform更新时，被钉住的值会和新的期望值打架。资源包里所有页面切换的 Timeline 一律显式写FillBehavior.Stop，结束态由代码显式清理，这样下一帧的布局计算永远从一个干净的状态出发。

4. 宿主与导航：TransitioningContentControl 的时序控制和打断处理

特效写得再好看，只要用户在动画没跑完时又点了一次菜单，问题就全出来了：页面重叠、白屏、按钮点不动、动画结束后内容还停在偏移位置。这一章讲的是时序控制，是特效包能不能实际用在真实后台里的分水岭。

4.1 两页叠加与切换时序

WPF 里做切换动画，两个页面的存在顺序决定了所有时序细节。常见的三种做法是：先卸载旧页再挂新页（会闪白）、新旧同时存在交叉动画（资源包采用）、以及先做一次截图再动画（性能开销大但最平滑）。

第一种做法在新页加载慢的时候会露出窗口背景色，后台系统里通常是一块白，非常刺眼。第二种做法的前提是宿主控件必须能在同一时刻持有两份内容，所以OldContent是独立依赖属性，而不是直接复用Content。第三种做法的思路是切换瞬间把旧页渲染成RenderTargetBitmap，用它代替真实视觉树做退场动画，好处是旧页的布局和绑定可以在动画开始前就释放掉，坏处是截图这一下本身就要几十毫秒，而且高 DPI 下容易出现模糊。资源包没有走截图路线，因为后台页面的视觉树本来就不重，两份共存的开销可以接受。

两页同时存在时，还有两个细节必须处理。一是焦点：旧页虽然被盖住，但它内部的输入框仍然可能持有键盘焦点，动画结束后旧页被移除，焦点会掉到窗口本身，用户再敲键盘就没反应了。稳妥的做法是在切换开始时把焦点强制挪到新页，或者给旧页套一层IsHitTestVisible="False"加Focusable="False"，让它安静地待在下层。二是命名域：两个页面的x:Name如果在同一父级下重复，会互相顶掉，导致绑定错乱；ContentPresenter各自维护自己的 NameScope，所以这一点通常不会出问题，但如果为了做动画把两个页面塞进同一个容器而不是两个 ContentPresenter，就要特别小心。

时序上还有一个参数值得单独拎出来：新旧两页的动画是否共用同一个Duration。共用看起来更整齐，实际效果是新页还没滑到位，旧页已经淡出成透明，中间有一瞬间屏幕上是空的。资源包里把旧页的淡出时长设成新页时长的 0.8 倍，让旧页先走完，新页还在动，视觉上会觉得内容一直是“连着”的。这个 0.8 不在代码里硬编码，放在TransitionPresets里，不喜欢就改。

4.2 导航服务、队列与中途打断

真正的后台系统里，用户点菜单的速度往往快于动画时长。如果每次点击都直接调SwitchTo，上一个 Storyboard 被Stop()掐掉、新动画从当前值重新开始，页面会不断从半路往回弹，看起来像抽搐。资源包的处理方式是用一个轻量状态机加请求队列：

// Navigation/NavigationService.cs private readonly Queue<NavigationRequest> _pending = new(); private bool _switching; public void Navigate(object view, TransitionKind kind) { if (_switching) { // 切换进行中：只保留最后一次请求，中间的直接丢弃 _pending.Clear(); _pending.Enqueue(new NavigationRequest(view, kind)); return; } DoNavigate(view, kind); } private void DoNavigate(object view, TransitionKind kind) { _switching = true; _host.SwitchCompleted += OnSwitchCompleted; _host.SwitchTo(view, kind); } private void OnSwitchCompleted(object sender, EventArgs e) { _host.SwitchCompleted -= OnSwitchCompleted; // 一次性订阅，必须解 _switching = false; if (_pending.Count > 0) { var next = _pending.Dequeue(); DoNavigate(next.View, next.Kind); } }

队列这里有个取舍值得说清楚：切换中又来新请求，是排队还是丢弃？如果排队，用户连点五下菜单，要等五次动画全部跑完，实际内容可能早就不是他想要的了；如果直接打断并SnapToEnd，页面会瞬间跳变，缺乏过渡。资源包选的是“只保留最后一个”，中间的直接清空，这样既不会积压，也不会丢掉用户最终想去的那一页。这个策略对菜单驱动的导航合适，但对“上一步/下一步”这种有序导航就不合适了，那种场景应该用真正的队列，一步步走。

打断时的动画处理也很关键。_board?.Stop()只是停下 Storyboard，被动画改过的属性会保持当前值，新动画如果从 0 开始而不是从当前值开始，画面会先跳一下。更精细的做法是用BeginAnimation加HandoffBehavior.SnapshotAndReplace，让新动画以当前值为起点；资源包里为了简单，滑动特效的From都是显式指定的，打断时确实会有一帧跳变，但因为动画被截断的时机通常在 100ms 以内、位移量还很小，肉眼基本看不出来。真要追求极致，就在SwitchTo里读一次TranslateTransform.X作为新的From，代价是代码复杂度上升，我一般不做。

导航栈这部分也要说一句。GoBack不只是把上一个 ViewModel 再塞回宿主，还要保证动画方向相反：前进用SlideLeft，后退就该用SlideRight，否则用户看着画面还在往左走，会以为又往前跳了一层。资源包把方向作为NavigationRequest的一部分带下去，TransitionFactory根据方向决定位移的正负号，这一层处理干净了，前进后退的视觉逻辑才能自洽。

5. 避坑清单：特效上线后最常见的五类翻车

这一章记录的是我自己和同行在真实项目里踩过的坑，全部有据可查，现象、原因、解决办法照着实操就能对上。

5.1 五条高频翻车记录：现象、原因、解决

现象一：切成两三次之后，页面内容偏移几十像素，越切越偏。原因几乎一定是FillBehavior用了默认的HoldEnd，动画终值被钉在TranslateTransform.X上，下一次切换再叠一个From，位移就累积了。解决办法是全部 Timeline 显式FillBehavior.Stop，并在Completed里显式把 Transform 重置回 0。我自己的写法是ResetTransform里直接重新 new 一个TranslateTransform换掉旧的，比逐属性赋 0 更不容易漏。

现象二：跑了十几分钟后内存缓慢上涨，任务管理器里私有内存一直往上走。最常见的原因是Completed事件没解绑。Storyboard 通过Completed事件持有委托，委托又回指控件，控件持有视觉树，视觉树持有 ViewModel——一整条引用链就挂住了。每次导航都+=一次而不-=，泄漏量就是每次导航留一整个页面。解决办法是在Completed处理器的第一行就-=自己，并且给Stop()之后也补一次解绑，因为Stop()不保证触发Completed。

现象三：开发机上丝滑，客户那台老机器上掉帧到十几帧。原因通常是动画动错了属性。Width、Height、Margin、Padding这类属性一改就触发重新测量和重新布局，一帧布局几十毫秒，帧率必然崩。所有切换特效只允许动Opacity和RenderTransform（以及Clip的几何值），这两类是渲染线程能直接处理的。另外给宿主 Grid 加CacheMode="BitmapCache"能把页面内容缓存成位图，滑动时少重绘一层，代价是文本在高 DPI 下可能轻微发虚，要不要开看页面里文字密度。

现象四：快速点击菜单，偶尔出现两个页面叠在一起，或者白屏半秒。前面说过Stop()不会清理旧内容，如果Completed因为被打断而没有触发，OldContent就一直挂在模板里，下次切换时旧层还显示着之前那张页面。解决办法是把清理逻辑从Completed里抽出来，做成一个ResetHost()方法，在SwitchTo开头、Stop()之后主动调一次；Completed里也调，两边幂等，谁先来都不会出问题。

现象五：设计器里好好的，运行起来特效完全不触发。三个常见原因：Generic.xaml没合进App.xaml的MergedDictionaries，控件退化成默认ContentControl模板，压根没有两个 ContentPresenter，_newPresenter为 null，代码里那句if (_newPresenter == null) { Content = newContent; return; }悄悄兜住了，等于没动画；第二是Begin(this, true)的第二个参数漏写；第三是资源用DynamicResource在窗口还没加载完时去取，取到 null 后面全部静默失败。这三个问题都不报错，只能靠断点逐个确认。

5.2 出问题时先看什么：定位手段与二分法

特效出问题，最痛苦的是不知道是动画没跑，还是跑了但没效果。我一般按这个顺序排查，从快到慢：

第一，在SwitchTo里打断点，确认_board不为 null 且Children.Count符合预期。为 null 说明走的是TransitionKind.None分支或者工厂里枚举没匹配上；Children 数量不对说明 Factory 里拼 Storyboard 的逻辑有分支漏了。

第二，给目标元素挂PresentationTraceSources.TraceLevel=High，XAML 里写成RenderTransform="{Binding ... , PresentationTraceSources.TraceLevel=High}"这种附加属性形式，动画的解析、应用、失败会在输出窗口里打出来，属性路径写错时能直接看到“找不到属性”的提示。这是排查属性路径问题最快的手段，比猜快得多。

第三，怀疑掉帧就在CompositionTarget.Rendering里打点，统计两次回调之间的时间差，超过 33ms 的帧计一次，跑十秒看丢帧比例。这个数字比肉眼判断准，也能证明到底是不是动画的问题——有时候你觉得卡，其实是数据加载在动画开始那一刻阻塞了 UI 线程。

第四，用二分法定位是动画本身还是页面内容。把TransitionKind临时改成Fade（只动 Opacity，成本最低），如果还是卡，那就是页面内容本身重，跟特效无关；如果突然丝滑，问题就在滑动/翻转特效的属性或者缓存策略上。这一招在我不确定要不要优化页面渲染时特别省时间。

6. 二次开发：加一个自定义特效并验证性能的三个习惯

往这套结构里加一个新特效，流程其实很短：在TransitionKind枚举里加一个名字，在TransitionFactory.Create的 switch 里加一个分支，分支里按第 3 章的写法造 Timeline，属性路径统一走RenderTransform.Children[1].(TranslateTransform.X)或者Opacity。只要不动 Width/Height/Margin，新特效天生就是布局友好的。

举一个我自己加过的例子，缩放入场：

// Transitions/TransitionFactory.cs 片段：缩放淡入 private static Storyboard BuildZoomFade(UIElement oldView, UIElement newView, Duration d) { var board = new Storyboard { FillBehavior = FillBehavior.Stop }; // 新页：0.94 放大到 1，同时淡入；两端都用 Stop，结束态交给 ResetTransform var scale = new DoubleAnimation { From = TransitionPresets.ZoomFrom, To = 1, Duration = d, EasingFunction = EaseFactory.Enter(), FillBehavior = FillBehavior.Stop }; Storyboard.SetTarget(scale, newView); Storyboard.SetTargetProperty(scale, new PropertyPath("RenderTransform.Children[0].(ScaleTransform.ScaleX)")); board.Children.Add(scale); // ScaleY 同参数再来一条，代码略；再给 oldView 加一条 1 → 0 的 Opacity 动画 return board; }

注意这里动的是Children[0]的ScaleTransform，正好是EnsureTransform预留的位置，两套 Transform 互不干扰，同一个页面可以既缩放又位移。加完之后一定要把TransitionPresets里相关的时长、起始比例补进去，不要在现场写魔数——我见过最难受的一版是时长散落在五个文件里，想统一调快一点得全局搜索。

验证方面，我自己有这三个习惯。第一，改动完在CompositionTarget.Rendering里跑十秒丢帧统计，滑动特效的丢帧率超过 5% 我就回去看是不是动了布局属性。第二，故意连续快切二十次，看内存是否回落、页面是否重叠——这是打断逻辑最容易暴露问题的地方。第三，在 125% 和 150% 缩放、以及一个 1366×768 的小窗口上各跑一遍，位移比例和裁剪边界的问题只有在这种环境才现形。

血泪教训是有一版我把滑动距离写死成 240 像素，自己 2K 屏幕上看着刚好，交付到客户的老笔记本上，页面只滑了不到四分之一屏就停住，用户以为卡住了。从那以后我每次做位移类动画都强制走一遍“距离 = 宿主尺寸 × 比例”的检查，哪怕代码看着啰嗦。希望帮到你。

本文还有配套的精品资源，点击获取