嵌入式MCU轻量级框架BabyOS v8.4.0：设备管理与模块化开发实战-编程实验室

简介：BabyOS框架v8.4.0是一套面向嵌入式系统与物联网开发的轻量级开源操作系统框架，适用于计算机专业本科生毕业设计、嵌入式课程实践及中小型IoT项目快速原型开发。资源包为18.9MB的ZIP压缩文件，包含完整源码工程（含任务调度、内存管理、中断处理等核心模块实现）、配套说明文档（如说明.htm）及可直接编译运行的示例工程，结构清晰、注释规范，便于理解操作系统底层机制并开展二次开发。目前已有56人学习下载，对操作系统原理教学、毕设选题落地及模板化建站类应用开发具有较强支撑作用——读者可基于该框架快速构建功能完备的嵌入式应用系统，聚焦算法设计与业务逻辑创新，显著降低底层驱动与内核适配门槛。

1. 项目概述：BabyOS，一个为嵌入式MCU量身定制的“婴儿级”操作系统框架

如果你是一名嵌入式开发者，尤其是经常和资源受限的微控制器（MCU）打交道的朋友，那么你一定对“如何在有限的RAM和Flash里优雅地组织代码”这个永恒的话题深有感触。裸机编程虽然直接，但随着功能模块增多，状态机写得人头晕眼花，模块间耦合也越来越高，维护起来简直是噩梦。上RTOS（实时操作系统）吧，像FreeRTOS、RT-Thread这些固然强大，但对于一些只有几十KB甚至几KB RAM的MCU来说，其内核开销和任务调度机制有时显得“杀鸡用牛刀”，学习成本和内存占用都可能成为项目瓶颈。

正是在这种背景下，BabyOS应运而生。它不是一个传统意义上抢占式或多任务的操作系统内核，而是一个面向MCU的轻量级应用框架。你可以把它理解为一个高度模块化、可裁剪的“软件积木箱”。它的核心目标不是管理任务调度，而是管理你的外设驱动、应用组件和业务逻辑，通过提供统一的设备管理、自动初始化、日志系统、参数存储等基础服务，让开发者能从繁琐的底层协调工作中解放出来，更专注于业务功能的实现。最新发布的v8.4.0版本，意味着这个框架在稳定性、功能性和易用性上又迈上了一个新台阶。无论你是想快速搭建一个产品原型，还是希望为现有项目引入更清晰的架构，BabyOS都值得你花时间深入了解。

2. BabyOS v8.4.0 核心设计思想与架构解析

2.1 “管理”而非“调度”：框架的定位哲学

与RTOS的核心是任务调度不同，BabyOS的核心是“设备管理”和“服务抽象”。它的设计哲学源于一个简单的观察：在大多数MCU项目中，最复杂的部分往往不是多任务并行，而是如何让UART、I2C、SPI、ADC、Timer等众多外设以及基于它们开发的传感器模块、显示模块、通信模块等，能够以统一、有序的方式被初始化、调用和管理，并且让它们之间能够低耦合地交换数据。

BabyOS的解决方案是引入了一个虚拟设备（BOS Device）的概念。每一个物理外设（如I2C1）或一个功能模块（如一个温湿度传感器SHT30），在BabyOS中都被抽象为一个虚拟设备，并分配一个唯一的设备句柄（handle）。框架内部维护一个设备链表，所有设备遵循统一的接口模型，包括初始化（init）、打开（open）、关闭（close）、控制（ioctl）和读写（read/write）等操作。这样一来，上层应用不需要关心底层是哪个具体的I2C端口驱动了传感器，它只需要通过“温湿度传感器设备”的句柄去读取数据即可。这种抽象极大地提高了代码的模块化和可移植性。

2.2 模块化与可裁剪性：应对资源受限环境的利器

BabyOS的整个框架由数十个独立的“模块”（Module）构成，例如：

驱动框架模块：为各类外设提供统一的驱动模型。
设备管理模块：核心，负责所有虚拟设备的注册、查找和管理。
自动初始化模块：定义并控制各模块初始化顺序，替代散乱的init()函数调用。
日志系统模块：提供分级（DEBUG, INFO, WARN, ERROR）日志输出，可重定向至串口、RTT等。
参数存储模块：提供类似NVRAM的键值对存储抽象，支持掉电保存，适配Flash、EEPROM等后端。
网络协议模块：可能包含轻量级的MQTT、CoAP客户端等（取决于版本和配置）。
实用工具模块：如CRC校验、环形缓冲区、命令行交互等。

最关键的是，这些模块绝大多数都是可选的。通过一个精美的配置文件（通常是b_config.h），你可以像点菜一样，选择项目需要的模块，关闭不需要的。编译器在链接时就会排除未选模块的代码，真正做到“按需索取”，这对Flash空间寸土寸金的MCU项目来说至关重要。

2.3 版本迭代至v8.4.0：稳定与功能的平衡

从版本号v8.4.0可以看出，BabyOS已经经历了相当长时间的迭代。通常，主版本号的提升意味着较大的架构调整或功能新增，而次版本号和修订号的提升则侧重于功能增强、优化和问题修复。v8.4.0版本很可能在以下方面进行了加强：

更丰富的驱动支持：持续增加对更多型号传感器、存储芯片、显示屏等常用元器件的官方驱动支持。
中间件完善：对文件系统（LittleFS等）、网络协议栈的集成和支持可能更加成熟稳定。
工具链与生态：配套的配置工具、示例代码和文档可能更加友好，降低了新手入门门槛。
性能与资源优化：对核心数据结构和算法进行微调，在保证功能的前提下进一步减少RAM和CPU占用。
问题修复：修复了之前版本社区反馈的已知问题，提升了框架的整体稳定性。

注意：在引入任何新框架时，务必查阅其官方发布日志（ChangeLog），明确v8.4.0相对于你已知版本的具体变化，评估其对你现有或新项目的收益与潜在风险。

3. 从零开始：BabyOS v8.4.0 项目搭建与移植详解

3.1 获取与解压：认识框架目录结构

从官方仓库或发布页面获取BabyOS-v8.4.0.zip并解压后，你会看到一个结构清晰的目录树。理解这个结构是成功使用的第一步。一个典型的BabyOS目录可能包含：

BabyOS/ ├── b_config.h.template // 核心配置文件模板，使用前需复制并重命名为b_config.h ├── bos/ // BabyOS核心源码目录 │ ├── core/ // 核心框架代码（设备管理、初始化、日志等） │ ├── drivers/ // 各类外设驱动（按传感器、存储、显示等分类） │ ├── hal/ // 硬件抽象层接口定义 │ ├── modules/ // 功能模块（参数存储、网络协议等） │ └── utils/ // 通用工具函数 ├── demo/ // 针对不同MCU平台的演示工程 │ ├── stm32f1xx/ │ ├── stm32f4xx/ │ └── ... ├── docs/ // 说明文档 └── tools/ // 可能包含一些辅助工具（如字体转换）

你的主要工作区域将集中在：1) 根据你的硬件修改b_config.h；2) 实现或适配hal层接口；3) 在drivers目录下查找或编写你的设备驱动；4) 参考demo创建你的应用工程。

3.2 核心配置：b_config.h 的精细化裁剪

b_config.h是整个BabyOS的“大脑”，你的第一个、也是最重要的任务就是配置它。不要直接修改模板，而是将其复制到你的项目目录并重命名为b_config.h。配置主要分为几大类：

基础功能开关：这是一系列以B_USE_开头的宏定义。

// 示例：启用或禁用核心模块 #define B_USE_DEVICE_MANAGER 1 // 必须为1，启用设备管理核心 #define B_USE_AUTO_INIT 1 // 启用自动初始化，强烈推荐 #define B_USE_LOG 1 // 启用日志系统 #define B_USE_LOG_COLOR 0 // 禁用彩色日志（节省终端解析开销） #define B_USE_PARAMETER 1 // 启用参数存储模块 #define B_USE_CMD 0 // 禁用命令行交互（如不需要调试shell）

硬件相关参数：根据你的MCU资源进行调整。

// 示例：设置设备最大数量和日志缓冲区大小 #define B_DEVICE_MAX_NUM 32 // 支持的最大虚拟设备数，根据实际需求调整，节省内存 #define B_LOG_BUFF_SIZE 256 // 单条日志最大长度 #define B_PARAM_MAX_SIZE 1024 // 参数存储区总大小（字节）

平台适配宏：告诉BabyOS你使用的编译器和MCU系列。

#define B_COMPILER_ARMCC // 使用ARMCC（Keil MDK） // 或 #define B_COMPILER_GCC // 使用GCC（如STM32CubeIDE） // 或 #define B_COMPILER_IAR // 使用IAR #define B_MCU_STM32 // 指定MCU为STM32系列

外设与驱动使能：选择你项目需要用到的具体驱动。

#define B_DRIVER_ENABLE_GPIO 1 #define B_DRIVER_ENABLE_UART 1 #define B_DRIVER_ENABLE_I2C 1 #define B_DRIVER_ENABLE_SHT3X 1 // 使能SHT3x温湿度传感器驱动 #define B_DRIVER_ENABLE_AT24CXX 1 // 使能AT24Cxx系列EEPROM驱动

实操心得：初次配置时，建议采取“最小化”原则，只打开你确定马上要用的模块。这可以避免引入未使用的代码，减少编译体积，也能让你更清晰地理解每个模块的依赖关系。随着功能增加，再逐步开启其他模块。

3.3 硬件抽象层（HAL）移植：连接框架与你的硬件

BabyOS通过硬件抽象层（HAL）来隔离底层硬件差异。框架在hal目录下为gpio、uart、i2c、spi、timer等提供了接口头文件（如b_hal_gpio.h），里面声明了框架期望调用的函数（如b_hal_gpio_init,b_hal_gpio_write）。但是，这些函数的实现需要你自己提供。

你需要在你工程的某个位置（通常是一个独立的hal目录）创建对应的.c源文件来实现这些函数。这些实现本质上是对你所使用的MCU SDK（如STM32的HAL库、标准外设库，或ESP32的IDF API）的一层薄封装。

例如，实现b_hal_i2c.c：

// b_hal_i2c.c #include “b_hal_i2c.h” #include “main.h” // 你的主头文件，包含了类似hi2c1这样的SDK对象 // 假设你的硬件I2C1对应BabyOS的I2C端口0 int b_hal_i2c_init(uint8_t i2c_num) { if (i2c_num == 0) { // 调用你的SDK初始化函数，MX_I2C1_Init()可能由CubeMX生成 MX_I2C1_Init(); return 0; // 返回0表示成功 } return -1; // 不支持的i2c端口号 } int b_hal_i2c_master_transmit(uint8_t i2c_num, uint16_t dev_addr, const uint8_t *data, uint16_t size, uint32_t timeout) { if (i2c_num == 0) { HAL_StatusTypeDef status = HAL_I2C_Master_Transmit(&hi2c1, dev_addr << 1, (uint8_t*)data, size, timeout); return (status == HAL_OK) ? 0 : -1; } return -1; } // ... 实现其他接口函数，如receive, mem_write, mem_read等

移植的关键点：

端口映射：确定BabyOS的虚拟端口号（如i2c_num=0）对应你硬件上的哪个实际外设（如I2C1）。
错误码转换：将底层SDK的错误状态（如HAL_ERROR）转换为BabyOS HAL接口约定的返回值（通常0成功，负数失败）。
功能完整性：不一定需要实现HAL头文件中的所有函数，只实现你项目中驱动会用到的即可。例如，如果只用主模式，从模式相关函数可以留空返回错误。

3.4 工程集成：将BabyOS源码加入你的编译系统

完成配置和HAL移植后，需要将BabyOS的源码文件添加到你的IDE或Makefile工程中。

对于Keil、IAR等IDE：

在工程中新建一个分组（Group），例如命名为BabyOS。
将bos/core、bos/drivers（选择你使能的部分）、bos/modules（选择你使能的部分）、bos/utils下的相关.c文件添加到该分组。注意，通常不需要添加hal目录下的.c文件，因为那是框架提供的接口定义，你的实现在别处。
将BabyOS的根目录以及bos下的各子目录添加到工程的“头文件包含路径（Include Paths）”中。

对于基于CMake或Makefile的工程：在你的构建脚本中，将BabyOS的源文件列表添加到编译源中，并正确设置包含路径。

编译与排查：第一次编译很可能会报错，常见问题包括：

找不到头文件：检查包含路径是否添加完整，特别是b_config.h的路径是否正确。
未定义的HAL函数：检查你的HAL实现文件是否被正确编译和链接。
宏定义冲突：检查b_config.h中的宏是否与你工程其他地方的宏重名。
内存溢出：如果编译成功但链接时提示内存不足，请返回b_config.h，进一步裁剪不必要的模块，或调小诸如缓冲区大小、设备最大数量等参数。

4. 核心功能实战：以数据采集与存储为例

假设我们要实现一个经典场景：通过I2C读取SHT30温湿度传感器数据，并将数据以及一些系统参数（如采集间隔）保存到AT24Cxx EEPROM中，同时通过串口打印日志。

4.1 设备注册与驱动查找

首先，确保在b_config.h中使能了相关驱动：B_DRIVER_ENABLE_I2C、B_DRIVER_ENABLE_SHT3X、B_DRIVER_ENABLE_AT24CXX、B_USE_LOG、B_USE_PARAMETER。

在应用代码中，我们不需要直接调用HAL函数，而是通过BabyOS的设备管理层来操作。

#include “bos.h“ // 包含BabyOS主头文件 // 声明设备句柄，用于后续操作 static b_device_t *sht30_dev = NULL; static b_device_t *eeprom_dev = NULL; void device_init(void) { // 1. 查找SHT30设备 // “sht3x“是驱动中定义的设备类型名 sht30_dev = b_device_find(“sht3x“); if (sht30_dev == NULL) { b_log(“ERROR: SHT30 device not found!\r\n“); // 可能是驱动未使能，或I2C HAL未正确实现 return; } // 2. 打开设备（可选，有些驱动在init时已隐含open） if (b_device_open(sht30_dev) != 0) { b_log(“ERROR: Failed to open SHT30 device!\r\n“); return; } // 3. 查找EEPROM设备 // “at24cxx“是驱动中定义的设备类型名 eeprom_dev = b_device_find(“at24cxx“); if (eeprom_dev == NULL) { b_log(“ERROR: EEPROM device not found!\r\n“); return; } b_device_open(eeprom_dev); b_log(“INFO: All devices initialized successfully.\r\n“); }

b_device_find函数会在框架内部维护的设备链表中，根据名称查找第一个匹配的设备。驱动在底层通过B_DRIVER_REGISTER宏，在编译时自动将自身注册到这个全局链表。这种设计实现了驱动的“自动发现”，应用层无需关心设备的具体型号（如SHT30还是SHT31）和硬件连接（接在哪个I2C口），只要驱动支持，查找就能成功。

4.2 使用统一接口进行数据读写

设备找到并打开后，就可以使用统一的read/write/ioctl接口进行操作。这些接口的第一个参数都是设备句柄。

读取传感器数据：

float temperature, humidity; uint8_t read_buf[6]; // SHT30一次读取6字节数据 void read_sensor_data(void) { if (sht30_dev == NULL) return; // 使用 read 接口读取原始数据 int ret = b_device_read(sht30_dev, 0, read_buf, sizeof(read_buf)); if (ret != sizeof(read_buf)) { b_log(“WARN: Failed to read from SHT30, ret=%d\r\n“, ret); return; } // 将原始数据转换为实际值（具体转换公式参考传感器手册） // 此处为示例，假设转换函数为 sht30_raw_to_float sht30_raw_to_float(read_buf, &temperature, &humidity); b_log(“INFO: Temp: %.2f C, Humidity: %.2f %%\r\n“, temperature, humidity); }

使用参数存储模块保存配置：参数存储模块提供了一个类似字典的持久化存储。我们用它来保存采集间隔。

#define PARAM_KEY_INTERVAL “sample_interval“ // 参数键名 uint32_t g_sample_interval_ms = 5000; // 默认5秒 void parameter_init_and_load(void) { // 初始化参数存储模块，指定后端存储设备（这里是eeprom_dev） b_param_init(eeprom_dev); // 从存储中加载参数。如果键不存在，则使用默认值，并自动保存。 b_param_get_uint32(PARAM_KEY_INTERVAL, &g_sample_interval_ms, 5000); b_log(“INFO: Sample interval loaded: %lu ms\r\n“, g_sample_interval_ms); } void update_interval(uint32_t new_interval) { g_sample_interval_ms = new_interval; // 更新参数值，并立即保存到存储设备 b_param_set_uint32(PARAM_KEY_INTERVAL, g_sample_interval_ms); b_log(“INFO: Sample interval updated to %lu ms\r\n“, g_sample_interval_ms); }

参数模块内部会处理数据的序列化、存储地址分配、磨损均衡（如果后端Flash支持）等细节，对应用层提供极其简单的get/set接口。

4.3 利用自动初始化简化启动流程

BabyOS的自动初始化模块允许你定义初始化函数及其优先级，框架在启动时（b_os_init()调用后）会自动按顺序执行它们，避免了在main函数里写一长串init调用。

// 在某个.c文件中，使用宏声明初始化函数 B_AUTO_INIT_HANDLER(device_init, 2); // 优先级2，设备初始化 B_AUTO_INIT_HANDLER(parameter_init_and_load, 3); // 优先级3，参数加载，依赖设备已就绪 // 在另一个.c文件（可能是网络模块） B_AUTO_INIT_HANDLER(network_init, 10); // 优先级10，网络初始化，放在后面 // 在main函数中，只需要调用 int main(void) { // 你的硬件底层初始化（时钟、GPIO等） hardware_init(); // BabyOS初始化，这会触发所有注册的自动初始化函数按优先级执行 b_os_init(); // 主循环 while(1) { read_sensor_data(); b_os_delay(g_sample_interval_ms); // 使用框架的延时，可能自动处理了系统心跳 } }

优先级数字越小，执行越早。通过合理规划优先级，可以清晰地管理模块间的依赖关系（如参数存储依赖EEPROM设备，EEPROM设备依赖I2C HAL初始化）。

5. 深入进阶：自定义驱动与模块开发

当内置驱动不满足需求，或需要接入一个全新的设备时，你需要编写自定义驱动。同时，你也可以将一些通用的业务逻辑封装成BabyOS风格的模块。

5.1 编写一个自定义传感器驱动

假设我们要为一款新的光照传感器BH1750编写驱动。

创建驱动文件：在bos/drivers/sensor/目录下（或你自定义的驱动目录）创建b_driver_bh1750.c和b_driver_bh1750.h。
定义设备操作集：这是驱动的核心，是一个包含函数指针的结构体。

// b_driver_bh1750.c #include “b_device.h“ static int bh1750_init(b_device_t *dev) { // 获取设备私有数据（如I2C端口号、设备地址） bh1750_info_t *info = (bh1750_info_t *)dev->private_data; // 调用HAL初始化I2C，发送BH1750初始化命令等 // ... return 0; } static int bh1750_read(b_device_t *dev, void *buf, size_t size) { bh1750_info_t *info = (bh1750_info_t *)dev->private_data; // 通过HAL I2C读取数据，并转换为lux值，写入buf // ... *(float *)buf = lux_value; return sizeof(float); // 返回读取到的数据字节数 } // 定义操作集 static const b_device_ops_t bh1750_ops = { .init = bh1750_init, .open = NULL, // 如果不需要单独打开操作，可设为NULL .close = NULL, .read = bh1750_read, .write = NULL, // BH1750通常只读 .ioctl = NULL, // 可选，用于实现模式切换等控制 };

定义设备信息与注册宏：

// 设备的私有数据，用于存储硬件相关信息 typedef struct { uint8_t i2c_num; // 使用的I2C端口号 uint8_t dev_addr; // I2C设备地址 } bh1750_info_t; // 实例化一个设备信息 static bh1750_info_t g_bh1750_info = { .i2c_num = 0, // 对应你的硬件I2C1 .dev_addr = 0x23, // BH1750的地址 }; // 使用注册宏，将驱动挂载到设备链表 // 参数：设备类型名， 设备操作集， 私有数据指针， 设备名（可空） B_DRIVER_REGISTER(bh1750, &bh1750_ops, &g_bh1750_info, NULL);

在b_config.h中使能驱动（如果需要条件编译）：

#define B_DRIVER_ENABLE_BH1750 1

在应用层使用：现在，你就可以像使用SHT30一样，使用b_device_find(“bh1750“)来查找并使用这个设备了。

5.2 创建业务逻辑模块

除了驱动，你还可以将复杂的业务逻辑封装成模块。例如，一个“数据上传管理器”模块。

创建模块文件：在bos/modules/或你项目的独立目录创建b_mod_uploader.c/h。
设计模块接口：定义清晰的对外的API。

// b_mod_uploader.h #ifndef _B_MOD_UPLOADER_H_ #define _B_MOD_UPLOADER_H_ int uploader_init(void); int uploader_set_data_source(float *temp, float *humi, float *lux); int uploader_trigger_upload(void); #endif

实现模块内部状态机与逻辑：在.c文件中实现。可以利用BabyOS提供的工具，如定时器（如果模块使能了）、日志、事件发布订阅等机制。
集成到自动初始化：在模块的初始化函数中，使用B_AUTO_INIT_HANDLER注册，使其在系统启动时自动初始化。

通过这种方式，你的应用层main函数将变得非常简洁，只需要触发uploader_trigger_upload()，具体的打包、协议处理、重试机制等都隐藏在模块内部，大大提升了代码的复用性和可维护性。

6. 调试技巧与常见问题排查实录

在实际使用BabyOS的过程中，你可能会遇到一些典型问题。以下是一些排查思路和调试技巧。

6.1 设备查找失败（b_device_find返回NULL）

这是最常见的问题之一。

检查驱动是否使能：确认b_config.h中对应的B_DRIVER_ENABLE_XXX宏已设置为1。
检查驱动注册宏：确保驱动源文件被正确添加到工程中参与编译，并且B_DRIVER_REGISTER宏被顺利执行（没有被条件编译排除）。
检查设备类型名：b_device_find的参数必须与驱动注册时使用的类型名（B_DRIVER_REGISTER的第一个参数）完全一致，包括大小写。
检查HAL依赖：该驱动可能依赖特定的HAL（如I2C），确认对应的HAL层函数已正确实现，并且初始化成功。有时驱动初始化（init函数）失败也会导致设备注册不成功，可以在驱动的init函数中添加日志打印。

6.2 日志系统不输出

检查日志使能与级别：确认B_USE_LOG为1，并且当前日志级别（可通过b_log_set_level设置或默认）低于或等于你打印语句的级别（如b_log(“INFO: ...“)）。
检查HAL_UART实现：日志默认重定向到b_hal_uart的某个端口（通常是端口0）。检查b_hal_uart.c中的b_hal_uart_write函数是否正确实现，是否指向了你的调试串口（如USART1）。
检查缓冲区与终端：确保串口终端软件（如Putty、SecureCRT）的波特率、数据位等设置与你的MCU配置一致。

6.3 参数存储读取错误或数据丢失

检查存储设备驱动：确认EEPROM/Flash驱动工作正常，能进行基本的读写。
检查参数存储区大小：B_PARAM_MAX_SIZE定义的大小必须小于等于你分配给参数存储的实际物理存储区大小。
注意地址对齐：有些Flash或EEPROM芯片要求写入地址按页对齐。确保在HAL层实现或驱动中处理了地址对齐问题。BabyOS的参数模块内部可能会连续写入，需要后端驱动保证原子性（至少页对齐写入）。
键名冲突：确保不同模块使用的参数键名是唯一的。

6.4 系统运行一段时间后异常复位

堆栈溢出：BabyOS内部会使用一些静态数组和缓冲区。检查b_config.h中定义的各项缓冲区大小（如B_LOG_BUFF_SIZE,B_DEVICE_MAX_NUM）是否设置过大，导致全局变量占用RAM过多，挤占了栈空间。
中断冲突：BabyOS的某些模块（如软件定时器）可能会使用系统滴答定时器（SysTick）中断或其他硬件定时器中断。确保与你的其他中断服务程序（ISR）没有冲突，且中断优先级配置合理。
内存泄漏：虽然BabyOS主要使用静态内存分配，但如果你在驱动或应用层使用了动态内存（malloc），需仔细检查。建议在资源受限的MCU上尽量避免动态内存分配。

6.5 性能优化建议

关闭调试功能：在发布版本中，将日志级别设置为B_LOG_LEVEL_ERROR或关闭日志（B_USE_LOG 0），可以显著减少代码大小和运行开销。
精细裁剪模块：定期审视b_config.h，关闭所有未使用的模块和驱动。
优化HAL函数：HAL层是频繁调用的热点。确保其实现高效，例如避免在b_hal_gpio_write中使用浮点运算或复杂的逻辑判断。
合理使用延时：在主循环中，尽量使用b_os_delay而非阻塞式延时，以便框架有机会处理后台任务（如软件定时器回调）。

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