windows 上 bluetoothfindfirstdevice 失败主因是蓝牙服务未开或未启用发现模式；linux 下 socket 操作需 cap_net_raw 权限；ble 连接须用专用 api，不可用普通 connect()；跨平台必须条件编译隔离实现。
Windows 上用 BluetoothFindFirstDevice 枚举设备失败，返回空列表
不是代码写错了，大概率是没开蓝牙服务或没启用发现模式。C++ 本身不处理蓝牙开关和配对状态，全靠系统 API 和用户权限兜底。
- 确保 Windows 设置里「蓝牙」已开启，且「允许设备查找此电脑」已勾选（否则
BluetoothFindFirstDevice只能扫到已配对设备） - 调用前必须先调用
BluetoothEnableDiscovery，否则多数设备不可见；但该函数需要管理员权限，普通用户进程会静默失败 -
BTH_ADDR类型的地址需用btaddrToString转成可读字符串，直接 printf 或 cout 打印会输出乱码
Linux 下用 hcitool 扫描正常，但 C++ 调 socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI) 报 Operation not permitted
Linux 蓝牙 socket 操作默认受 cap_net_raw 限制，普通用户无权访问 HCI 设备。这不是权限设置问题，而是内核强制策略。
- 运行程序前加
sudo setcap cap_net_raw+ep ./your_program（仅需一次），避免每次 sudo 启动 - 不要试图用
geteuid() == 0判断是否 root——即使 root，缺 cap 也会失败 -
AF_BLUETOOTH在较老内核（如 4.4 以下）可能未定义，编译前检查linux/bluetooth.h是否存在且版本匹配
连接 BLE 设备时 connect() 阻塞超时，或立即返回 Connection refused
BLE 和传统蓝牙（BR/EDR）协议栈完全不同，connect() 对 BLE 地址根本无效。C++ 标准 socket API 不支持 BLE GATT 交互，必须走专用库。
- Linux 推荐用
libbluetooth的gatttool封装逻辑，或更现代的bluezD-Bus API（需链接libdbus-1） - Windows 上只能用 WinRT 的
Windows::Devices::Bluetooth::Advertisement::BluetoothLEAdvertisementWatcher，但 C++/CX 或 C++/WinRT 是硬性依赖，纯 Win32 不行 - 别在
connect()后立刻发数据——BLE 连接建立后还需 service discovery 和 characteristic discovery，跳过会直接断连
跨平台项目里混用 BlueZ 和 WinRT 头文件，编译报 unknown type name 'BluetoothLEDevice'
头文件和链接行为完全不兼容，没有“统一抽象层”这种好事。条件编译不是可选项，是必选项。
立即学习“C++免费学习笔记（深入）”；
- 用
#ifdef __linux__/#ifdef _WIN32隔离蓝牙初始化、扫描、连接三段逻辑，不要共用 struct 或回调函数签名 - 避免在头文件里
#include <windows.h></windows.h>或<bluetooth></bluetooth>，放到 .cpp 里并用 PIMPL 隐藏实现细节 - BlueZ 的
hci_dev_info和 WinRT 的BluetoothAdapter行为差异极大：前者要手动打开 hci0，后者自动枚举所有适配器——别指望一个初始化函数通吃
蓝牙通信最麻烦的从来不是连上，而是连上之后怎么知道对方支持哪些 service、characteristic 怎么读写、MTU 怎么协商、丢包了怎么重传。这些都得按协议栈一层层抠，没捷径。
