企业官网建设流程全解析

简介：本资源是一个面向汽车工程专业学生、新能源控制系统研究人员及Simulink仿真初学者的串联混合动力汽车动态建模与仿真学习包，聚焦于能量管理策略验证与多动力源协同控制原理理解。压缩包共619个文件，涵盖137个MATLAB脚本（m）、57个Simulink模型（slx）、64个仿真数据（mat）、165张结构/波形图（jpg/png）以及HTML报告、DOCX需求文档和C语言S-Function源码等，完整支撑模型搭建、参数调试、结果分析与代码级扩展，总大小24.3MB。已有380人下载学习，适用于课程设计、毕业设计及科研原型验证场景。用户可直接运行主模型观察发动机启停逻辑、电机扭矩分配、制动能量回收过程，并基于内置的能源管理模块（含PID与规则逻辑）开展策略对比实验；配套的系统需求文档与S-Function底层实现（含.c/.def/.exp文件）有助于深入理解实时仿真接口与控制算法嵌入机制。 做串联混动整车模型的这些年，我最大的感受是：很多人拿到一个Simulink模型文件，先急着打开看模块，而不是先想清楚这个模型到底在算什么。串联混合动力汽车模型这种东西，表面看是电池、电机、发动机、发电机几个大块拼在一起，实际核心是功率流的分配和能量管理策略的落地。驱动需求功率从车轮一路反推到发动机和电池，每一步都在做能量转换的效率折损，建模的精度和价值全藏在功率流骨干里。所以我决定把手头这套串联混合动力汽车Simulink模型的搭建思路完整梳理一遍，包括架构怎么分层、关键子系统怎么建、能量管理策略怎么嵌入、调试中踩过的坑怎么处理，以及模型如何向工程应用延伸，给准备入门混动建模的同行一条可以反复对照的路径。

1. 先聊清楚串联混动的架构：模型背后的物理逻辑

1.1 为什么建模前必须搞懂功率流方向

串联混合动力和并联、混联相比，最大的结构特点是发动机不直接连接车轮，发动机只带动发电机发电，电能进入母线，和电池的电能汇合后，统一由驱动电机驱动车轮。这听起来简单，但里面有一个非常关键的物理约束：整车需求功率和发动机输出功率之间隔着好几层能量转换。

• 发动机化学能 → 机械能，效率大概在30%到40%；
• 发电机机械能 → 电能，效率可以达到90%到95%；
• 驱动电机电能 → 机械能，效率通常在88%到94%；
• 最后还有机械传动和轮胎滚动损失。

也就是说，发动机发出的每1千瓦功率，真正落到车轮上可能只有0.7千瓦左右。反过来看电池路径，电池放电的效率可以达到95%以上，但由于电池能量密度低，它只是一个能量缓冲器，不能作为长途行驶的持续能量来源。所以在模型里，发动机-发电机组的容量必须按照"平均功率需求"来设计，而不是按照"峰值功率需求"来设计，峰值需求由电池来顶。这个逻辑是所有串联混动能量管理策略的出发点，也是模型里一串参数的取值依据。

1.2 串联拓扑在Simulink里的表达方式

在Simulink里表达串联拓扑，我个人推荐的方式是用物理信号表达功率流，用普通Simulink信号表达控制流。功率流用功率值（kW）表示，控制流用发动机启停标志、扭矩指令、转速指令等表示。这样模型的层次感非常清晰，调试时也容易定位问题。

一个标准的串联混动Simulink模型，顶层至少应该包含这几个子系统：

• 整车控制器VCU：接收驾驶员需求、车辆状态、SOC等信息，输出发动机启停指令、发电机功率指令、驱动电机扭矩指令；
• 发动机-发电机组：接收功率/转速指令，输出燃油消耗量和产生的电功率；
• 动力电池：接收母线功率需求，输出SOC、端电压、允许放电/充电功率；
• 驱动电机：接收扭矩指令，输出驱动扭矩或回馈扭矩；
• 车辆动力学：包括整车质量、滚阻、风阻、坡度、传动比和车轮模型，计算车速；
• 驾驶员模型：根据目标车速和实际车速的偏差，输出加速/制动踏板信号。

控制流和功率流的连接方式，我通常是从VCU发出指令到各个执行器子系统，再从执行器子系统反馈实际状态给VCU，形成一个闭环。功率流方面，各子系统的功率会在一个功率母线节点汇总，用Add模块求和，确保功率守恒。这里有一个容易被忽视的点：Simulink的代数求解器不会自动保证功率守恒，功率母线求和的残差如果大于1瓦，说明某个子系统的功率计算有误，要优先排查这个。

2. 顶层模型搭建：从空模型到可跑通的原型

2.1 Simulink模型分层与命名规范

我在搭建整车模型时，始终坚持一个原则：顶层只放子系统，不直接放底层的Gain、Transfer Fcn之类的模块。顶层应该像一张系统框图，双击任意子系统进入下一层，每层只解决一个抽象层次的问题。这样做的好处是，模型文件在后期维护时，你不需要滚动很久才能找到某个模块。

使用到的分层方法如下：

• 第0层：整车控制器、驾驶员、动力系统、车辆动力学等大子系统；
• 第1层：动力系统内部再拆发动机、发电机、电池、电机；
• 第2层：发动机内部再拆扭矩计算、油耗MAP、热模型等。

命名规范上，我使用这样的前缀区分类型：

• VCU_开头的是整车控制器相关模块；
• Eng_开头的是发动机相关模块；
• Gen_开头的是发电机相关模块；
• Batt_开头的是电池相关模块；
• Mot_开头的是驱动电机相关模块；
• Veh_开头的是整车动力学相关模块。

信号线也要命名，而且名字要能表达信号含义，比如Mot_Torque_Cmd、Batt_SOC、Veh_Velocity。不命名的信号线是最坑的，后期别人接手（或者你自己隔一个月再看）根本不知道那根线连的是什么。我自己的习惯是，打开模型之后第一件事就是按Ctrl+Shift+F检查有没有未命名信号线，有的话全部补齐。

2.2 驾驶员模型与工况输入的处理

模型要跑起来，必须有输入。串联混动模型的输入通常有几种：标准工况（NEDC、WLTC、CLTC）、自定义车速谱、爬坡+加速复合工况。我一般把工况数据放在Excel或MATLAB脚本里，通过From Workspace模块或者Signal Editor导入模型。

驾驶员模型本质上是一个PID控制器：

• 输入：目标车速和实际车速；
• 输出：加速踏板开度（0到1）或制动踏板开度（0到1）；
• 调节逻辑：目标车速大于实际车速时，增大加速踏板；目标车速小于实际车速时，施加制动或滑行。

PID参数标定时，比例系数不能太大，否则踏板波动剧烈，模型容易产生振荡。我常用的做法是先设定P为0.3到0.5，I为0.05到0.1，D为0，跑一遍看看踏板响应。如果踏板频繁在0和1之间跳变，说明P偏大。

这里有个容易踩的坑：加速踏板开度和制动踏板开度不能同时大于0。所以在驾驶员模型的输出端，我会加一个死区和互锁逻辑：只有车速偏差超过某个死区（比如0.1km/h）才输出踏板信号，且加速踏板信号和制动踏板信号取反相。

3. 关键子系统建模细节：电池、电机、发动机-发电机组

3.1 电池模型选型：从等效电路到热影响

电池是串联混动里最需要认真对待的子系统，因为它承担着削峰填谷的核心功能。我在模型里使用的是二阶RC等效电路模型，相比一阶RC，它能更准确地表达电池在动态工况下的电压响应。

二阶RC的核心方程是：

• 端电压：V_t = V_oc(SOC) - I_internal * R_0 - V_1 - V_2；
• 两个RC网络的动态：dV_1/dt = I_internal/C_1 - V_1/(R_1*C_1)，dV_2/dt = I_internal/C_2 - V_2/(R_2*C_2)；
• SOC积分：SOC(t) = SOC(0) - ∫ I_internal/(Q_batt*3600) dt。

参数方面，开路电压V_oc和SOC的关系是一组数据点，通常从电池厂商的OCV-SOC曲线获得；R_0、R_1、C_1、R_2、C_2在不同SOC和不同温度下也是不同的。在模型中，我使用二维Lookup Table来存这些参数，一维是SOC，一维是温度。

如果你不想从零搭建电池模型，也可以使用Simscape Battery工具包里的电池模块，它自带电热耦合、老化模型，直接拖出来配置参数就能用。但这里有个关键区别：等效电路模型运行速度快，适合策略开发和MIL测试；Simscape Electrochemical模型精度更高，但仿真速度慢很多，不适合跑完整工况。在整车能量管理策略开发阶段，我建议先用等效电路模型，策略验证完成后再决定是否用高保真模型做特定场景的确认。

电池最大允许充电功率和放电功率，是VCU最重要的输入之一。在估计电池功率限制时，要考虑：

• 当前SOC下电池能承受的最大持续电流；
• 当前温度下电池的功率能力衰减；
• 端电压上下限对功率的限制。

在模型里，我会建一个Batt_Power_Limit子系统，输出Batt_Discharge_Power_Limit和Batt_Charge_Power_Limit，这两个值直接送到VCU的能量管理模块，防止策略请求超过电池能力。

3.2 驱动电机外特性与效率MAP

驱动电机在模型中承担两个角色：驱动和制动能量回收。电机建模最常用的方式是外特性曲线+效率MAP。

外特性曲线表达的是电机在不同转速下的最大扭矩和最大功率：

• 基速以下为恒扭矩区，最大扭矩等于峰值扭矩；
• 基速以上为恒功率区，最大扭矩等于峰值功率除以当前转速；
• 峰值扭矩必须考虑持续时间限制（通常30秒），持续扭矩要低于峰值扭矩。

效率MAP是一张二维表，横轴是转速，纵轴是扭矩（或功率），表里存的是电机效率值。在模型中，给定当前转速和扭矩指令，通过Lookup Table查效率，再计算实际消耗的电功率：

P_elec = P_mech / η当电机驱动时；

P_elec = P_mech * η当发电回馈时。

这里有个细节容易出错：回馈制动时，P_mech是负值（因为机械功率从车轮流入电机），但效率查表时应该用扭矩的绝对值查效率，最后再把符号乘回去。如果你直接用负扭矩去查效率表，插值结果完全是错的。

电机模型的动态响应，我用一阶惯性环节近似：

T_actual = 1/(τ_motor*s+1) * T_command

τ_motor一般取20到50毫秒，这可以表达电机扭矩响应的延迟特性。在纯策略验证阶段，也可以把这一阶惯性环节去掉，直接用静态查表，因为策略仿真关注的是能量管理逻辑，不是电机控制器的动态响应。但如果你想做系统级稳定性分析，一阶惯性环节必须保留。

3.3 发动机-发电机组：转速功率协调

发动机-发电机组在串联混动里相当于"车载发电厂"，它的控制目标是在最佳油耗区域内发电。这里有几个关键问题：

• 发动机工作在什么转速？
• 发动机输出多少功率？
• 发电机扭矩如何跟随发动机？

我采用的方式是发动机转速闭环控制+发电机功率闭环控制：VCU根据当前整车需求功率和电池SOC状态，决定发动机-发电机组的输出功率指令，然后查找该功率下的最佳工作转速，这个转速通常由"最低燃油消耗率曲线"（最小BSFC曲线）确定。

发动机的油耗率BSFC（g/kWh）是转速和扭矩的二维表。最小BSFC曲线就是这张表上每个功率等值线上的最低点连成的线。串联混动的核心目标之一，就是把发动机的工作点尽量压在这条曲线附近。

发动机子系统的动态，我用的是均值模型（Mean Value Engine Model），核心是计算发动机扭矩响应和油耗：

• 油耗率：m_dot_fuel = BSFC(转速, 扭矩) * P_engine / 3600，单位是kg/s；
• 发动机扭矩响应：用一阶惯性环节近似，时间常数0.3到0.5秒；
• 发电机扭矩指令：等于发动机扭矩乘以一个传动比（如果发动机和发电机之间有增速齿轮）。

一个实际的工程经验：发动机启停之间有一个最小工作时间限制，不能频繁启停。所以在VCU的能量管理策略里，需要加入发动机最小运行时间计时器。例如，发动机一旦启动，至少运行30秒；一旦停机，至少停机10秒。这样做是为了避免发动机在低SOC边界处反复启停，既费油又影响排放。

4. 能量管理策略的实现：恒温器加功率跟随的落地方式

4.1 策略分层和控制状态机的搭建

能量管理策略是串联混动模型的灵魂。在基于规则的策略中，我首推恒温器策略加功率跟随的混合策略，它既不复杂，又比纯恒温器策略更高效。

纯恒温器策略的逻辑是：当SOC低于下限（比如35%）时启动发动机，并让发动机以固定功率发电；当SOC达到上限（比如45%）时停机。这个策略实现简单，但发动机启停频繁，在低SOC时持续高功率输出，效率不是最优。

功率跟随策略的逻辑是：发动机功率跟随整车需求功率，电池只负责弥补供需差。这个策略效率高，但发动机工作点波动大，经常运行在低效率区间。

两者结合的CS（Charge Sustaining）策略逻辑：

当SOC处于正常工作区间（比如45%到75%）：

• 整车需求功率P_demand小于某个阈值（比如10kW）时，发动机停机，纯电驱动；
• P_demand超过10kW时，发动机启动，P_engine = P_demand（功率跟随），发电机直接供电驱动电机，电池既不充电也不放电；
• SOC低于45%时，进入充电模式，P_engine = P_demand + P_charge_adj，其中P_charge_adj是额外给电池充电的功率，取值根据SOC偏差来计算。

在Simulink中，这个逻辑我用Stateflow状态机来实现，主要状态有：

• Off：发动机关闭，纯电模式；
• PowerFollow：发动机功率跟随，维持SOC；
• Charge：发动机发电并给电池充电；
• Eng_Starting：发动机启动过渡状态，防止模式切换瞬间扭矩突变。

状态转移条件是SOC和P_demand的组合。为了防止频繁切换，状态转移必须有滞回区间。举例来说，从Off到PowerFollow的触发条件是P_demand > 10kW，但从PowerFollow回到Off的条件是P_demand < 6kW，这个4kW的滞回带能有效避免功率在阈值附近时状态抖动。

4.2 发动机启停和模式切换的平滑过渡

能量管理策略里，最容易出问题的地方不是稳态逻辑，而是模式切换瞬间。发动机启动时有响应延迟、扭矩波动、振动噪声，这些在物理台架上都是问题，在模型里至少要能体现出来。

我处理模式切换的方式是加入过渡状态和斜坡限制：

• 发动机启动指令发出后，先进入Eng_Starting状态，此时发动机转速爬升到目标转速，发电机扭矩从零开始斜坡增加到目标值，斜坡时间设为1到2秒；
• 驱动电机扭矩在模式切换瞬间保持连续，不能因为发动机发电功率突变导致母线电压波动，进而影响驱动扭矩输出。

实现时，我会在VCU输出端加一个Slew Rate Limiter模块，限制发动机功率指令的变化率，比如每秒最多变化10kW。同时在模式切换时，用Switch模块在前后两个模式的输出之间做线性插值过渡，时间常数0.5秒。

这里有一个非常重要但又容易被忽略的细节：母线功率平衡。在串联混动中，驱动电机消耗的功率等于发动机-发电机组产生的功率加上电池放电功率，再减去各部件DC/DC变换器的损耗。在模型里，如果这三个功率不平衡，母线电压就会出现不正常的波动。发现这种情况时，我会用一个Sum模块把母线节点功率求和，加上一个Scope观察残差，残差超过5%就要检查是哪个子系统的功率计算有问题。

5. 模型调试中的踩坑记录与验证方法

5.1 代数环和单位问题

Simulink模型跑起来经常遇到的两个问题：代数环和单位错误。代数环的出现通常是因为信号在同一个时间步内互相依赖，没有延迟环节。在整车模型里，代数环最容易出现在"驾驶员模型-整车控制器-动力系统-车辆动力学"这个大反馈回路里。

解决代数环的常用方法：

• 在反馈回路中插入Memory或Unit Delay模块，打破代数依赖；
• 在反馈回路中插入一阶惯性环节，用动力学延迟替代纯代数关系；
• 如果可以接受，将模型的求解器设置为discrete，并在反馈路径中加入离散延迟。

我个人更倾向于在反馈回路中加入一阶惯性环节，这样更符合物理实际。比如车速反馈给驾驶员模型时，车速本身就是由积分得到的，不会形成代数环；但扭矩指令从VCU输出到电机模型，如果电机模型是静态查表，这里的反馈路径就可能形成代数环。所以电机模型的一阶惯性环节不仅模拟物理动态，还能顺带打破代数环。

单位问题在Simulink中需要特别留意。Simulink要求信号有明确的单位，但默认不检查。我在模型里会给每个信号线设置单位：

• 功率：kW；
• 扭矩：N·m；
• 转速：rpm；
• 车速：km/h；
• SOC：无量纲（0到1）。

我的做法是在信号线名里加上单位后缀，比如Mot_Torque_Cmd_Nm、Veh_Speed_kmh。这样做的一个直接好处是，当你连接两个子系统时，单位名称不一致的信号一眼就能看出来。如果你使用Simscape模块，单位检查会更严格，混用kW和W会导致仿真结果差好几个数量级。

5.2 仿真步长、数据记录和结果验证

整车型号仿真的步长选择，需要在仿真速度和精度之间找平衡。对于策略开发阶段，我使用变步长求解器ode45或ode15s，最大步长设置为0.1秒，这样既能捕捉到模式切换的动态，又不会让仿真时间过长。一个完整的WLTC工况（1800秒），在普通笔记本上通常跑5到15分钟。

数据记录方面，我使用Simulink Data Inspector（SDI），在仿真结束后能直观地看所有信号曲线。我通常会记录的关键信号包括：

• 车速目标值和实际值；
• SOC曲线；
• 发动机工作点（转速、扭矩、油耗）；
• 电池功率和母线功率；
• 驱动电机扭矩和转速；
• 模式切换信号。

结果验证的第一步，是检查车速跟踪质量。目标车速和实际车速的偏差应在1km/h以内，如果偏差超过这个值，说明驾驶员模型PID参数不合适，或是车辆驱动力不足。第二步是检查SOC曲线，SOC在CS阶段结束时应该和初始值相差不大，比如初始50%，结束时应控制在45%到55%之间，如果SOC持续下降，说明能量管理策略的发电功率不足，需要增大P_charge_adj。第三步是看发动机工作点，把发动机工作点画在一张以转速为横轴、扭矩为纵轴的图上，再叠加上BSFC等值线，看工作点是否集中在低油耗区间。这一步很直观，工作点越靠近低油耗中心，策略越有效。

5.3 常见边界问题和模型鲁棒性

模型在标准工况下跑通只是第一步，真正考验模型质量的是边界工况。我在测试时通常会准备几个特殊场景：

• 全油门加速至最高车速，检查电机扭矩保护是否触发，电池放电功率是否超过限制；
• 长下坡制动，检查回馈制动功率是否超过电池充电功率限制，多余能量是否通过制动电阻消耗（如果模型里有）或机械制动介入；
• 高温低温环境（电池温度模型），检查功率限制是否生效，防止过温导致模型失效。

这里有一个经常被忽视的坑：模型初始化。整车模型是一个包含多个积分环节的系统，如果初始条件设置不合理，仿真开始阶段会出现剧烈振荡。比如车辆初始速度设为0，但驾驶员模型在0.1秒内就发出全油门指令，车速在很短时间冲到几十km/h，这在实际车上是不可能发生的，但模型里如果不加限制就会出现。所以我在加速度踏板输出端会加一个速率限制器，限制踏板开度变化率每秒不超过100%（也就是0到1至少要1秒），这样模型启动会更平稳。

6. 从模型到工程应用的延伸思考

6.1 模型参数化与自动化标定

当模型搭建完成并跑通之后，下一步就是参数化和标定。整车模型的参数很多，包括整车质量、滚动阻力系数、风阻系数、传动比、电池容量、电机峰值功率等。这些参数散落在模型各个子系统中，后期管理非常麻烦。

我推荐的做法是集中参数化管理：

• 在MATLAB脚本或Simulink.Parameter对象中定义所有参数；
• 在模型中使用参数名替代具体数值；
• 通过Model Explorer统一管理信号和参数属性；
• 将参数按子系统分组，加注释说明来源和单位。

这样做的好处是，当你需要做整车轻量化仿真、电池容量选型、电机功率匹配时，只需要修改参数脚本，重新运行模型就可以得到新的结果，不需要一个一个去模型里改数字。这也是后续做参数敏感性分析的基础。

进一步地，你可以批量跑不同参数组合，例如parfor并行计算不同电池容量下的油耗和SOC维持能力。我在标定时经常用这种方式，写一个循环，把电池容量从20Ah到60Ah每隔5Ah跑一遍WLTC，然后画出油耗和SOC的关系曲线，帮助做电池选型决策。

6.2 从MIL到代码生成：策略模型的工程化路径

模型的价值不仅仅在于仿真，更重要的是它可以沿着V模型流程向工程落地。在MIL（Model in the Loop）测试通过之后，控制策略模型可以进一步做代码生成，生成C代码刷写到VCU硬件或用于HIL（Hardware in the Loop）测试。

在模型设计阶段，就应该为代码生成做好准备：

• 使用支持代码生成的模块，避免使用From Workspace、To Workspace这类仿真专用模块；
• 使用Input/Output端口定义策略模型的接口，不要直接在模型里读全局变量；
• 离散化控制策略，因为VCU的软件是离散采样运行，采样周期一般是10ms或20ms；
• 使用Fixed-Step求解器和离散求解器，保证代码生成的仿真结果与实车行为一致。

这里需要特别提醒的是，能量管理策略模型和整车被控对象模型要分开。整车模型包含发动机、电池、电机等物理系统，这些大多是连续时间模型，不适合直接生成代码刷到VCU；而能量管理策略是控制算法，才是代码生成的目标。所以我在项目里总是保持两个模型的独立性：一个HEV_Plant.slx整车对象模型，一个HEV_Strategy.slx策略模型。两者通过接口信号连接，MIL测试时一起仿真，代码生成时只生成HEV_Strategy.slx的代码。

HIL测试时，把生成的控制代码刷到实时机中，整车对象模型运行在另一台实时仿真机里，通过IO板卡交换信号。因为整车对象模型必须满足实时性要求，所以Simscape高保真模型往往跑不动，需要将对象模型降阶。这时候，前面说的一阶惯性代替动态、MAP查表代替微分方程这些模型简化手段，就体现出价值了。

还有一个经验值得分享：在代码生成阶段，一定要关注Stateflow状态图生成的代码质量和可读性。如果状态图内部有复杂的转移冲突，生成代码中会出现大量关于状态的switch-case嵌套，代码运行效率会下降，而且不利于后续在硬件上的调试。所以写状态图时要保持状态数量精简，转移条件清晰，尽量用父子状态来组织复杂逻辑，降低状态图复杂度。

关于环境配置和模块依赖的一些补充

搭建串联混动模型需要的软件环境，我当前常用的是MATLAB R2022a及以上版本，Simulink和Simscape是核心组件。如果用到电池模型，还需要Simscape Battery工具包；如果做代码生成，需要Simulink Coder和Embedded Coder。在模型交付时，这些依赖关系也需要提前整理清楚，避免对方打开了模型却跑不起来。

不同版本的MATLAB对模型文件的兼容性比较敏感，高版本保存的模型低版本打不开。所以在团队协作时，我会约定好统一使用某个版本，并在保存模型时使用Save as Previous Version导出兼容版本，但要注意高版本的功能模块在低版本中可能不支持，最好在交付前在目标版本中打开验证一次。

另外，如果模型里使用了Simscape物理网络模块，要注意物理网络信号和普通信号之间的连接。Simscape模块使用物理信号线（Physical Signal），不能直接连接普通的Simulink信号线，需要通过PS-Simulink Converter和Simulink-PS Converter进行转换，转换时还要设置好单位。很多人第一次混合使用Simulink和Simscape时，卡得最多的就是这里。

最后分享一个实用小技巧

调试串联混动模型时，我发现一个非常好用的方法：把能量管理策略的每个状态转移条件都单独引到Scope上。例如发动机启动条件是P_demand > 10kW，我用一个Compare To Constant模块把条件真假输出出来，连到Scope上，再叠加实际P_demand曲线一起看。这样就能直观看到，在哪些时间段条件被满足、发动机为何在这个时刻启动。排查模式切换异常问题时，这个方法比盯着状态机的状态流程看高效得多。

另外，跑完整工况仿真时，每次记录数据都保存成MAT文件，文件名加上工况名称、SOC初始值、策略名称和日期。比如THS_WLTC_SOC50_RuleV3_20240512.mat，这样时间久了回头找数据时，不用打开文件就能知道这个结果是用什么参数跑出来的。整车模型开发是个长周期工作，数据的可追溯性非常重要，这个习惯能帮你省下很多时间。

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