ESP32 BLE开发实战：破解5大连接与缓存难题的工程级方案

当你完成第一个ESP32 BLE demo的喜悦还未散去，现实问题便接踵而至——设备突然失联、服务神秘消失、通知时有时无...这些问题往往让开发者陷入无休止的重启和重连循环。本文将直击这些"教科书不会教"的实战痛点，用工程思维拆解问题本质。

1. 幽灵连接：设备无法自动重连的幕后真相

许多开发者发现，一旦BLE连接断开，ESP32就像陷入昏迷状态，再也无法被客户端发现。这通常源于BLE协议栈的状态机管理缺陷。ESP32的BLE库在默认情况下不会在断开后自动恢复广播，需要手动触发重连机制。

核心修复方案是植入服务器回调函数。以下代码展示了如何实现断线自动重播：

cpp复制class ServerCallbacks: public BLEServerCallbacks {
    void onConnect(BLEServer* pServer) {
        Serial.println("Device connected");
    }
    void onDisconnect(BLEServer* pServer) {
        // 关键修复：断开后立即重启广播
        BLEDevice::startAdvertising();
        Serial.println("Advertising restarted after disconnect");
    }
};

void setup() {
    BLEDevice::init("ESP32-BLE");
    BLEServer *pServer = BLEDevice::createServer();
    pServer->setCallbacks(new ServerCallbacks()); // 注册回调
    // ...其他初始化代码
}

注意：Android和iOS设备有不同的重连策略。iOS通常更积极地尝试重连，而Android可能需要手动触发。

2. 服务消失之谜：破解手机BLE缓存机制

最令人困惑的现象莫过于：明明烧录了新固件，手机却显示旧服务。这其实是手机OS的BLE缓存机制在作祟——它们会缓存服务特征以减少重复发现