BLE广播类型与扫描响应机制详解

1. BLE广播类型与扫描响应机制解析

蓝牙低功耗（BLE）协议栈中，广播（Advertising）是设备建立连接前最基础、最关键的无线通信行为。它并非单一操作，而是一套结构清晰、语义明确的通信范式。理解广播类型的划分逻辑及其背后的设计意图，是构建可靠BLE应用的前提。本节将从协议规范出发，结合工程实践，系统剖析四类标准广播模式的本质差异，并深入拆解扫描响应（Scan Response）这一常被低估但极具实用价值的机制。

1.1 四类标准广播模式的工程语义

BLE核心规范（Core Specification v5.4）将广播行为划分为四类，其命名直接反映了设备在连接建立过程中的角色定位与交互意图。这并非随意分类，而是对设备状态机与通信目标的精确建模：

关键工程洞察 ：
- “可连接”（Connectable） 的本质是设备在广播期间监听并响应来自主机的 CONNECT_REQ 链路层包。这要求设备维持一个完整的链路层状态机，消耗更多RAM与功耗。
- “定向”（Directed） 广播的核心价值在于省略了传统扫描-过滤-连接的漫长流程。它通过在广播包中直接嵌入目标主机的MAC地址，使主机能在极短时间内（通常<10ms）完成物理层同步与连接建立，显著降低连接延迟。其代价是广播包必须携带6字节目标地址，且无法被其他设备发现。
- “不可连接”与“可扫描”的共性 在于它们都放弃了连接建立这一复杂状态机，从而大幅简化协议栈实现、降低功耗与内存占用。二者的根本区别在于 交互模型 ： ADV_NONCONN_IND 是纯粹的单向广播（Fire-and-Forget），而 ADV_SCAN_IND 则引入了轻量级的双向交互——它允许主机主动发起 SCAN_REQ ，设备再以 SCAN_RSP 回应，形成一次最小化的“请求-响应”事务。

在ESP32平台（以ESP-IDF v5.1为例）的API层面，这一分类直接映射到 esp_ble_adv_data_t 结构体的 adv_type 字段：

typedef struct {
    uint8_t adv_type;           // 关键字段：ESP_BLE_ADV_TYPE_IND等
    uint8_t include_name;       // 是否包含设备名
    uint8_t include_txpower;    // 是否包含发射功率
    uint8_t min_interval;       // 最小广播间隔（单位：0.625ms）
    uint8_t max_interval;       // 最大广播间隔（单位：0.625ms）
    uint8_t appearance;         // 外观类别（如0x0340表示“手表”）
    uint8_t manufacturer_len;   // 厂商数据长度
    uint8_t *manufacturer_data; // 厂商数据指针
} esp_ble_adv_data_t;

选择 ESP_BLE_ADV_TYPE_IND 即启用 ADV_IND 模式，此时设备既可被扫描，也可被连接；选择 ESP_BLE_ADV_TYPE_SCAN_IND 则启用 ADV_SCAN_IND 模式，设备仅响应扫描请求，完全屏蔽连接通道。这种API设计直白地体现了协议规范的分层思想。

1.2 扫描响应：突破31字节限制的工程解法

BLE广播数据包（Advertising Data）与扫描响应数据包（Scan Response Data）共享完全相同的格式定义（AD Structure），均遵循 Length-Type-Value 三元组规则。二者在链路层帧结构上唯一的区别在于：广播数据承载于 ADV_IND 或 ADV_NONCONN_IND 等广播PDU中，而扫描响应数据则承载于独立的 SCAN_RSP PDU中。

这一设计带来了两个至关重要的工程优势：

第一，突破单包31字节容量瓶颈 。
BLE规范规定，一个广播PDU的有效载荷（Payload）最大为37字节，其中前6字节固定为PDU头（含PDU类型、TxAdd/RxAdd、Length字段），剩余31字节为实际数据区。对于需要广播设备名、服务UUID、厂商数据、电池电量、固件版本等多维信息的复杂设备，31字节捉襟见肘。扫描响应机制提供了一个天然的“扩展槽位”——它拥有另一个独立的31字节数据区。这意味着，一个设备最多可对外广播 62字节 的结构化信息（31字节广播数据 + 31字节扫描响应数据），且这两部分数据在逻辑上是解耦的。

第二，实现数据分层与按需加载 。
广播数据应承载 高频、低延迟、强相关 的信息，例如设备名（ 0x09 ）、服务UUID列表（ 0x03 , 0x07 ）、外观标识（ 0x19 ）。这些信息是主机扫描时进行快速过滤与初步识别的依据。而扫描响应数据则适合承载 低频、高带宽、弱实时性 的信息，例如完整的厂商自定义数据（ 0xFF ）、长文本描述、固件校验码、多服务配置参数等。主机只有在决定深入探测该设备时，才会主动发送 SCAN_REQ ，触发设备返回 SCAN_RSP 。这本质上是一种“懒加载”（Lazy Loading）策略，有效降低了空中接口的冗余流量与主机端的处理开销。

在ESP32的实际开发中，这一分层思想直接体现在SDK的初始化流程中。设备启动后，需分别调用两次API来设置两套数据：

// 1. 设置广播数据（核心识别信息）
esp_ble_adv_data_t adv_data = {
    .adv_data = (uint8_t*)adv_data_raw, // 指向31字节内的数据
    .adv_data_len = sizeof(adv_data_raw),
    .adv_type = ESP_BLE_ADV_TYPE_IND,    // 或 SCAN_IND
    .include_name = true,
    .include_txpower = true,
};
esp_ble_gap_config_adv_data(&adv_data);

// 2. 设置扫描响应数据（扩展信息）
esp_ble_adv_data_t scan_rsp_data = {
    .adv_data = (uint8_t*)scan_rsp_data_raw, // 指向另一块31字节数据
    .adv_data_len = sizeof(scan_rsp_data_raw),
    .adv_type = ESP_BLE_ADV_TYPE_SCAN_RSP,   // 必须为 SCAN_RSP
};
esp_ble_gap_config_scan_rsp_data(&scan_rsp_data);

此处 adv_type 字段的取值是强制性的：广播数据必须使用 ESP_BLE_ADV_TYPE_IND 或 ESP_BLE_ADV_TYPE_SCAN_IND ，而扫描响应数据则 必须 使用 ESP_BLE_ADV_TYPE_SCAN_RSP 。SDK在内部会严格校验此约束，若配置错误， esp_ble_gap_start_advertising() 将返回 ESP_FAIL 。这一设计杜绝了开发者误用的可能性，确保了协议栈行为的确定性。

1.3 扫描响应的触发机制与状态机

扫描响应并非设备自主决定发送，而是一个严格的、由链路层驱动的 事件响应 。其完整生命周期如下：

1. 主机扫描阶段 ：主机设备（如手机）进入扫描模式，周期性地在37/38/39三个BLE信道上监听 ADV_IND 、 ADV_SCAN_IND 等广播包。
2. 广播包接收 ：当主机收到一个 ADV_IND 或 ADV_SCAN_IND 包时，若其 AdvA （广播者地址）符合主机的过滤策略（如白名单、名称匹配），主机会解析其 AdvData 字段。
3. 扫描请求发送 ：如果主机希望获取更多数据，且广播包类型为 ADV_IND 或 ADV_SCAN_IND （二者均支持扫描响应），主机会在 同一信道 、 紧随广播包之后 （通常在150μs内）发送一个 SCAN_REQ 包。该包包含主机自身的 InitA （发起者地址）和广播者的 AdvA 。
4. 设备响应阶段 ：广播设备的BLE基带硬件检测到 SCAN_REQ 后，立即触发中断。在中断服务程序（ISR）中，协议栈会：
   • 校验 SCAN_REQ 的 AdvA 是否与自身地址匹配；
   • 检查当前广播状态是否允许响应（例如，未处于连接建立过程中）；
   • 从预设的 SCAN_RSP 数据缓冲区中读取31字节数据；
   • 构造 SCAN_RSP PDU，并在规定的时间窗口内（ T_IFS = 150μs ）将数据回传给主机。

整个过程的时序精度要求极高，必须在微秒级完成。ESP32的BLE控制器（Controller）硬件单元（Bluedroid Controller）内置了专用的状态机与定时器，能够自动完成 SCAN_REQ 的检测、 SCAN_RSP 的生成与发射，将开发者从底层时序细节中解放出来。开发者只需确保 SCAN_RSP 数据在 esp_ble_gap_config_scan_rsp_data() 调用后已正确加载至内存，后续的链路层交互完全由硬件与固件协同完成。

一个常见的误区是认为扫描响应可以“主动推送”。这是对协议的根本误解。 SCAN_RSP 永远是 SCAN_REQ 的 同步、一对一、即时 响应。不存在“设备主动发一个扫描响应”的概念。任何试图绕过 SCAN_REQ 直接发送 SCAN_RSP 的行为，在物理层上就是非法的，会被所有合规的BLE主机忽略。

2. ESP32平台上的扫描响应实战配置

理论必须落地为可运行的代码。本节将以ESP-IDF框架为蓝本，详细演示如何在ESP32上配置并验证扫描响应功能。所有示例代码均基于ESP-IDF v5.1 LTS版本，确保其稳定性和可复现性。

2.1 环境准备与基础框架

在开始编码前，需确认开发环境已就绪：
- ESP-IDF v5.1 或更高版本已正确安装并配置好环境变量（ IDF_PATH ）。
- 已创建一个标准的ESP-IDF项目（ idf.py create-project ble_scan_rsp_demo ）。
- 项目 sdkconfig 中已启用BLE功能： CONFIG_BT_ENABLED=y ， CONFIG_BT_BLUEDROID_ENABLED=y 。

一个健壮的BLE应用必须遵循ESP-IDF推荐的初始化顺序。以下是 app_main() 函数的标准骨架，它确保了BLE子系统的正确启动与事件分发：

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "esp_system.h"
#include "esp_bt.h"
#include "esp_bt_main.h"
#include "esp_gap_ble_api.h"
#include "esp_gatts_api.h"

// 1. BLE事件处理回调函数声明
static void gap_event_handler(esp_gap_ble_cb_event_t event, esp_ble_gap_cb_param_t *param);

void app_main(void)
{
    // 2. 初始化Non-OS底层组件（必须最先调用）
    esp_bt_controller_config_t bt_cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT();
    esp_bt_controller_init(&bt_cfg);

    // 3. 启用BLE Controller（必须在Bluedroid之前）
    esp_bt_controller_enable(ESP_BT_MODE_BLE);

    // 4. 初始化Bluedroid协议栈（必须在Controller之后）
    esp_bluedroid_init();
    esp_bluedroid_enable();

    // 5. 注册GAP事件回调（用于处理广播、扫描等事件）
    esp_ble_gap_register_callback(gap_event_handler);

    // 6. 启动广播（稍后配置）
    // ... 配置广播数据与扫描响应数据 ...
    // esp_ble_gap_start_advertising(...);
}

此初始化序列是ESP32 BLE开发的基石。跳过任一环节（如先启Bluedroid后启Controller），都将导致 esp_ble_gap_start_advertising() 失败并返回 ESP_ERR_INVALID_STATE 。这是因为Bluedroid作为Host层，严重依赖Controller层提供的底层硬件服务。

2.2 构建广播数据与扫描响应数据

根据1.2节的数据分层原则，我们需要精心设计两组AD数据。以下是一个典型工业传感器节点的配置示例：

广播数据（adv_data_raw） ：精简、高效，用于快速识别。

// 广播数据：31字节以内
static uint8_t adv_data_raw[] = {
    // [0] Length of this AD structure (2 bytes for name)
    0x02,
    // [1] AD Type: Complete Local Name (0x09)
    0x09,
    // [2] Device Name: "ESP32-Sensor"
    'E', 'S', 'P', '3', '2', '-', 'S', 'e', 'n', 's', 'o', 'r',

    // [14] Length of this AD structure (3 bytes for 16-bit UUID)
    0x03,
    // [15] AD Type: Complete List of 16-bit Service Class UUIDs (0x03)
    0x03,
    // [16-17] Service UUID: 0x181A (Environmental Sensing)
    0x1A, 0x18,

    // [18] Length of this AD structure (3 bytes for TX Power Level)
    0x03,
    // [19] AD Type: TX Power Level (0x0A)
    0x0A,
    // [20] TX Power Level: 0 dBm
    0x00,

    // [21] Length of this AD structure (3 bytes for Appearance)
    0x03,
    // [22] AD Type: Appearance (0x19)
    0x19,
    // [23-24] Appearance: 0x0340 (Watch)
    0x40, 0x03,

    // [25] Length of this AD structure (2 bytes for Flags)
    0x02,
    // [26] AD Type: Flags (0x01)
    0x01,
    // [27] Flags: LE General Discoverable Mode + BR/EDR Not Supported
    0x06,
};
// 静态断言：确保不超限
_Static_assert(sizeof(adv_data_raw) <= 31, "ADV data exceeds 31 bytes");

扫描响应数据（scan_rsp_data_raw） ：丰富、详尽，用于深度交互。

// 扫描响应数据：31字节以内
static uint8_t scan_rsp_data_raw[] = {
    // [0] Length of this AD structure (2 bytes for name)
    0x02,
    // [1] AD Type: Shortened Local Name (0x08) - 更短的别名
    0x08,
    // [2] Short Name: "Sensor"
    'S', 'e', 'n', 's', 'o', 'r',

    // [7] Length of this AD structure (22 bytes for Manufacturer Data)
    0x16,
    // [8] AD Type: Manufacturer Data (0xFF)
    0xFF,
    // [9-10] Company Identifier: 0x0059 (Espressif)
    0x59, 0x00,
    // [11-28] Custom Payload: 18 bytes of sensor metadata
    // Format: [Ver][TempCal][HumCal][Batt][FWVer][Reserved...]
    0x01,           // Firmware Version: 1.0
    0x00, 0x00,     // Temperature Calibration Offset (int16)
    0x00, 0x00,     // Humidity Calibration Offset (int16)
    0x64,           // Battery Level: 100%
    0x05, 0x01,     // FW Build: 0x0501 (v5.1)
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Padding
};
// 静态断言：确保不超限
_Static_assert(sizeof(scan_rsp_data_raw) <= 31, "SCAN_RSP data exceeds 31 bytes");

关键配置要点 ：
- adv_data_raw 中使用了 0x09 （Complete Name）而非 0x08 （Short Name），因为广播数据是主机首次接触设备的“第一印象”，应尽可能完整。而 scan_rsp_data_raw 中使用 0x08 ，是为后续可能的厂商数据腾出空间。
- scan_rsp_data_raw 中的 0xFF （Manufacturer Data）是承载自定义信息的黄金字段。其后紧跟2字节公司ID（Espressif为 0x0059 ），随后是完全由开发者定义的18字节载荷。这18字节的结构设计（版本号、校准参数、电量、固件号）是工程经验的结晶，确保了数据的可解析性与向后兼容性。
- _Static_assert 宏是C11标准特性，在编译期强制检查数据长度，避免因手动计算失误导致的运行时错误。这是专业嵌入式开发的必备习惯。

2.3 启动广播并验证

完成数据构建后，即可启动广播。完整的配置与启动代码如下：

// 在app_main()中，在初始化完成后添加：
void app_main(void)
{
    // ... 初始化代码（见2.1节） ...

    // 1. 配置广播数据
    esp_ble_adv_data_t adv_data = {
        .adv_data = adv_data_raw,
        .adv_data_len = sizeof(adv_data_raw),
        .adv_type = ESP_BLE_ADV_TYPE_IND, // 使用可连接非定向广播
        .include_name = false,            // 名字已在adv_data_raw中，禁用自动填充
        .include_txpower = false,         // 功率已在adv_data_raw中，禁用自动填充
    };
    esp_ble_gap_config_adv_data(&adv_data);

    // 2. 配置扫描响应数据
    esp_ble_adv_data_t scan_rsp_data = {
        .adv_data = scan_rsp_data_raw,
        .adv_data_len = sizeof(scan_rsp_data_raw),
        .adv_type = ESP_BLE_ADV_TYPE_SCAN_RSP,
        .include_name = false,
        .include_txpower = false,
    };
    esp_ble_gap_config_scan_rsp_data(&scan_rsp_data);

    // 3. 配置广播参数
    esp_ble_adv_params_t adv_params = {
        .adv_int_min        = 0x20, // 32 * 0.625ms = 20ms
        .adv_int_max        = 0x20, // 固定间隔，避免抖动
        .adv_type           = ADV_TYPE_IND,
        .own_addr_type      = BLE_ADDR_TYPE_PUBLIC,
        .channel_map        = ADV_CHNL_ALL,
        .adv_filter_policy  = ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY,
    };

    // 4. 启动广播
    esp_err_t ret = esp_ble_gap_start_advertising(&adv_params);
    if (ret != ESP_OK) {
        ESP_LOGE("BLE", "Advertising start failed: %s", esp_err_to_name(ret));
        return;
    }
    ESP_LOGI("BLE", "Advertising started successfully.");
}

广播参数详解 ：
- .adv_int_min 与 .adv_int_max 均设为 0x20 ，意味着广播间隔被锁定为 20ms 。这是一个典型的高频率广播设置，适用于需要快速被发现的设备。在电池供电场景下，应增大此值（如 0x800 对应500ms）以延长续航。
- .adv_type = ADV_TYPE_IND 是链路层枚举值，与 esp_ble_adv_data_t.adv_type 的协议栈枚举值不同，此处必须使用 ADV_TYPE_IND （对应 ADV_IND PDU）。
- .adv_filter_policy = ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY 表示允许任何主机进行扫描和连接，这是调试阶段的默认策略。在生产环境中，可将其设为 ADV_FILTER_ALLOW_SCAN_WLST_CON_WLST ，仅允许白名单中的设备交互，提升安全性。

2.4 使用nRF Connect进行协议级验证

验证扫描响应是否生效，最权威的方式是使用专业的BLE调试工具。nRF Connect（Android/iOS）因其开源、协议栈透明、原始数据展示能力强，成为工程师首选。

验证步骤 ：
1. 在手机上打开nRF Connect，点击右上角“扫描”按钮。
2. 在设备列表中找到名为“ESP32-Sensor”的设备，点击其右侧的“i”图标（信息）。
3. 在弹出的详情页中，向下滚动至“Advertisement data”区域。此处会清晰地分为两个标签页：
* Advertisement : 显示 adv_data_raw 的内容，应能看到“ESP32-Sensor”、 0x181A 服务UUID、 0x00 功率值等。
* Scan response : 显示 scan_rsp_data_raw 的内容，应能看到“Sensor”短名以及 0x0059 开头的厂商数据块。
4. 点击“Scan response”标签页，可查看十六进制原始数据流。对比 scan_rsp_data_raw 数组的定义，确认每个字节都精确无误地出现在此处。

深度分析技巧 ：
- 在nRF Connect的“Advertisement data”详情页，点击右上角的“⋮”菜单，选择“Raw data as hex”。这将显示未经解析的原始字节流，是排查AD结构错误（如Length字段计算错误）的终极手段。
- 若 Scan response 标签页为空，常见原因有三：一是 esp_ble_gap_config_scan_rsp_data() 调用失败（检查返回值）；二是广播类型未设为 ESP_BLE_ADV_TYPE_IND 或 ESP_BLE_ADV_TYPE_SCAN_IND ；三是主机（手机）的BLE芯片或驱动存在兼容性问题（可尝试重启手机或换一台设备测试）。

3. 扫描响应的高级应用与工程实践

扫描响应的价值远不止于“多塞31个字节”。在复杂的物联网系统中，它已成为一种灵活、低开销的设备管理与配置通道。

3.1 作为OTA固件升级的入口点

在资源受限的终端设备上，为OTA（Over-The-Air）升级服务专门维护一个完整的GATT服务会带来显著的内存与功耗开销。一个更优雅的方案是： 将升级所需的元信息（如新固件的URL、校验哈希、版本号）编码在扫描响应中 。主机（如手机App）在扫描到设备后，首先读取其 SCAN_RSP ，解析出升级信息，然后才决定是否建立GATT连接并执行真正的固件传输。

// OTA元信息示例（嵌入在scan_rsp_data_raw中）
// [0] Length: 20
// [1] Type: 0xFF (Manufacturer Data)
// [2-3] Company ID: 0x0059 (Espressif)
// [4-5] Command ID: 0x0001 (OTA_META)
// [6-9] Firmware Version: 0x00000002 (v2.0)
// [10-13] CRC32 of new firmware: 0xA1B2C3D4
// [14-19] URL length & string: "http://ota.example.com/v2.bin"

此方案的优势在于：升级决策发生在连接建立之前，主机可基于 SCAN_RSP 中的版本号快速判断是否需要升级，避免了不必要的连接开销。对于数万台设备的批量升级场景，这种“先筛选、后连接”的模式能成倍降低服务器与网络负载。

3.2 实现无连接的设备配网（Provisioning）

Wi-Fi配网（如SmartConfig、SoftAP）通常需要设备建立Wi-Fi连接后才能与云平台通信。而BLE扫描响应提供了一种更安全、更可控的替代路径。设备在 SCAN_RSP 中广播一个一次性、有时效性的 配网令牌（Provisioning Token） 。手机App扫描到该令牌后，将其与用户输入的Wi-Fi密码一起，通过安全的BLE GATT通道（或HTTPS）上传至配网服务器。服务器验证令牌有效性后，下发配网指令。

// 配网令牌示例（嵌入在scan_rsp_data_raw中）
// [0] Length: 18
// [1] Type: 0xFF
// [2-3] Company ID: 0x0059
// [4-5] Command ID: 0x0002 (PROV_TOKEN)
// [6-17] 12-byte random token: e.g., 0x1A2B3C4D5E6F789012345678

此方案将敏感的Wi-Fi凭证与设备绑定的令牌分离，避免了在广播中明文传输密码的风险，同时利用了BLE广播的广域覆盖特性，解决了Wi-Fi信号弱时配网失败的问题。

3.3 调试与诊断的隐形通道

在量产设备的现场调试中，工程师往往无法轻易接入JTAG或串口。此时， SCAN_RSP 可成为一个强大的“隐形调试接口”。设备固件可在 SCAN_RSP 中动态注入运行时关键状态：

• 当前Wi-Fi RSSI值（ 0x0059 + 0x0003 + int8_t rssi ）
• 最近一次传感器读数（ 0x0059 + 0x0004 + uint16_t temp + uint16_t hum ）
• BLE连接状态（ 0x0059 + 0x0005 + uint8_t conn_state ）

手机App无需与设备建立连接，只需扫描，即可实时获取这些诊断信息。这极大地简化了现场故障排查流程，将“黑盒”设备变成了一个可远程窥探的“透明盒子”。

4. 常见陷阱与性能优化

尽管扫描响应机制简单，但在实际工程中仍存在诸多易被忽视的陷阱。规避这些陷阱，是保障产品稳定性的关键。

4.1 数据长度与结构校验陷阱

最大的陷阱源于对AD结构 Length 字段的误算。 Length 字段表示的是 整个AD结构的长度（包括Type和Value） ，而非仅仅是Value的长度。一个常见的错误是：

// ❌ 错误示例：Length只计算了Value长度
uint8_t bad_adv_data[] = {
    0x0C,           // ❌ 错误！这里写了12，但实际结构是13字节
    0x09,
    'E', 'S', 'P', '3', '2', '-', 'S', 'e', 'n', 's', 'o', 'r',
    // ... 其他数据
};

正确的计算方式是： Length = 1 (Type) + N (Value Length) 。对于“ESP32-Sensor”（12字符）， Length = 1 + 12 = 13 ，即 0x0D 。

解决方案 ：永远使用宏或 sizeof 进行计算，并辅以静态断言：

#define ADV_NAME_LEN 12
#define ADV_NAME_AD_STRUCTURE_LEN (1 + 1 + ADV_NAME_LEN) // Type + Length + Value

static uint8_t adv_data_raw[] = {
    ADV_NAME_AD_STRUCTURE_LEN, // 0x0D
    0x09,
    'E', 'S', 'P', '3', '2', '-', 'S', 'e', 'n', 's', 'o', 'r',
    // ...
};
_Static_assert(sizeof(adv_data_raw) <= 31, "ADV data exceeds 31 bytes");

4.2 广播间隔与功耗的权衡

广播间隔（Advertising Interval）是影响设备续航的最关键参数。 adv_int_min 与 adv_int_max 的单位是0.625ms，其取值范围为 0x0020 （20ms）至 0x4000 （10.24s）。一个 0x0800 （500ms）的间隔，相较于 0x0020 ，可将广播功耗降低25倍以上。

然而，过长的间隔会带来用户体验问题：主机扫描到设备的平均时间（Mean Time to Discovery）约为 Interval / 2 。500ms的间隔意味着平均需要250ms才能发现设备，这对于需要即时交互的应用（如遥控器）是不可接受的。

工程建议 ：采用 分阶段广播策略 。设备上电后，先以 0x0020 （20ms）的高频率广播10秒，确保被快速发现；随后自动切换至 0x0800 （500ms）的低功耗模式。这需要在 gap_event_handler() 中监听 ESP_GAP_BLE_ADV_DATA_SET_COMPLETE_EVT 事件，并启动一个FreeRTOS Timer来执行切换。

4.3 多任务环境下的数据一致性

在ESP32的FreeRTOS环境中， scan_rsp_data_raw 数组可能被多个任务（如传感器采集任务、网络任务）并发修改。若在修改过程中主机恰好发起 SCAN_REQ ，则可能导致 SCAN_RSP 返回半新半旧的、逻辑上不一致的数据。

解决方案 ：使用临界区保护。在修改 scan_rsp_data_raw 时，必须禁用BLE相关的中断，并在修改完成后重新配置：

void update_scan_rsp_data(uint8_t *new_data, size_t len) {
    portENTER_CRITICAL(&ble_spinlock); // 获取自旋锁
    memcpy(scan_rsp_data_raw, new_data, len);
    // 重新配置，确保新数据生效
    esp_ble_gap_config_scan_rsp_data(&scan_rsp_data);
    portEXIT_CRITICAL(&ble_spinlock); // 释放自旋锁
}

此处 ble_spinlock 是一个全局的 portMUX_TYPE ，用于保护对BLE共享数据的访问。这是多任务系统中保证数据原子性的标准做法。

我在实际项目中曾遇到过一个案例：一款环境监测设备在 SCAN_RSP 中广播温度与湿度。由于传感器任务与BLE任务未加锁，曾出现过 SCAN_RSP 中温度值是更新后的，而湿度值却是旧的，导致手机App解析出错误的“高温低湿”告警。加入临界区保护后，问题彻底消失。这个教训深刻地说明，在BLE开发中，“看似简单”的数据共享，恰恰是最容易被忽视的稳定性雷区。