开源 BLE 协议栈横评：NimBLE、Zephyr、BTstack、BlueZ 怎么选

做 BLE 产品，绕不开一个问题：协议栈用谁的？芯片原厂 SDK（Nordic SoftDevice、TI、乐鑫、沁恒…）当然能用，但一旦你想跨平台、想看得见源码、想避开黑盒和授权费，开源协议栈就成了主角。这篇把最主流的四个开源 BLE 栈——NimBLE、Zephyr、BTstack、BlueZ——从定位、许可证、架构到选型场景讲清楚，帮你在立项时少走弯路。

一、先分清：一个"协议栈"到底包含哪几块

BLE 协议栈不是铁板一块，选型前必须先知道你要的是哪一层：

• Controller（控制器）：链路层 LL + 物理层 PHY，通常跑在蓝牙芯片固件里，和射频强绑定。
• Host（主机）：GAP / GATT / ATT / SMP / L2CAP / HCI，是纯软件，可移植。
• Profile / 应用：心率、OTA、透传等业务逻辑。

HCI 是 Host 与 Controller 的分界线。有的开源栈是"全栈"（Host + Controller 都给，单芯片能跑），有的只做 Host（需要外接一颗带 Controller 的芯片，通过 HCI 对接）。这个区别直接决定它能不能在你的芯片上单片跑起来——下面每个栈都会点明。

二、四大开源栈逐一拆解

2.1 Apache NimBLE：小而美的 MCU 首选

• 出身：Apache Mynewt 项目的蓝牙栈，Apache 基金会背书。
• 许可证：Apache 2.0，可闭源商用、无传染性、含专利授权，对商业产品最友好。
• 覆盖范围：全栈（Host + Controller 都有），也可只用 Host 部分。
• 平台：主打 Nordic nRF52 / nRF53；最重要的是它被乐鑫官方移植成 esp-nimble，是 ESP32 系列的默认 BLE 栈之一（相比 Bluedroid 更省 RAM/Flash）。
• 特点：代码体积极小（Host 部分典型不到 50 KB Flash），模块化、可裁剪，特别适合纽扣电池传感器、可穿戴这类资源紧张的场景。支持 BLE Mesh。
• 适合谁：做 nRF52 / ESP32 低功耗终端、想要小体积 + 商用友好许可的团队。

2.2 Zephyr Bluetooth：功能最全、最"正统"的选择

• 出身：Zephyr RTOS 的蓝牙子系统（subsys/bluetooth），Linux 基金会旗舰项目，Intel、NXP、Nordic、TI 等一票大厂共建。
• 许可证：Apache 2.0（少量导入组件另有许可，注意甄别），同样商用闭源友好。
• 覆盖范围：全栈，Host + Controller 都实现，且通过了 Bluetooth SIG 认证——用 Zephyr 栈的产品可直接继承其 Qualified Design ID，省一大笔认证功夫。
• 平台：多架构（ARM Cortex-M / RISC-V / x86），支持 Nordic、STM32、NXP、Silicon Labs 等。Nordic 已把新产品（nRF53 / nRF54 等）主推方向从 nRF5 SDK + SoftDevice 迁到了 Zephyr。
• 特点：功能覆盖最全（全角色、无限连接数、LE Secure Connections、Mesh 1.1、方向查找等），文档一流，社区极活跃。代价是"重"——它本质是一整套 RTOS，学习曲线陡、构建系统（west / Kconfig / devicetree）有门槛。
• 适合谁：新立项、想押注长期主线、需要 SIG 认证省事、能接受 RTOS 学习成本的团队。

2.3 BTstack：嵌入式老兵，双许可的商业解

• 出身：德国 BlueKitchen 出品，专为嵌入式/MCU 设计，历史悠久、久经量产考验。
• 许可证：双许可模式——开源版 GPLv2（免费但有传染性），另有商业授权 可付费买断、绕开 GPL。很多 TWS / 音频厂商走的就是商业授权这条路。
• 覆盖范围：只做 Host（BLE + 经典蓝牙 Classic 都支持），Controller 靠外接芯片经 HCI 对接。这也是它能适配海量芯片的原因。
• 特点：采用 polling（轮询）架构，不依赖 RTOS、可裸机运行，事件驱动、内存占用可控、可移植性极强（从 8 位单片机到 Linux 都能跑）。是少数把 BLE + Classic（A2DP / HFP / SPP）都做扎实的开源栈。
• 适合谁：做经典蓝牙音频、需要裸机/无 OS 运行、愿意为省心买商业授权的团队。

2.4 BlueZ：Linux 官方栈，网关和上位机的事实标准

• 出身：Linux 官方蓝牙协议栈，随内核发行，桌面/服务器/嵌入式 Linux 上的默认选择。
• 许可证：GPL-2.0（用户态部分含部分 LGPL）。注意：它以独立进程（bluetoothd 守护进程）+ D-Bus 接口对外服务，你的应用通过 D-Bus 调用，通常不构成对你应用代码的 GPL 传染——这点和把 GPL 库静态链进固件是两回事，是它能在商业 Linux 产品里广泛使用的关键。
• 覆盖范围：只做 Host（BLE + Classic 全套），Controller 由 Linux 内核 + 蓝牙适配器芯片提供，经 HCI（USB / UART）对接。
• 特点：功能最全、最稳定，配套工具链完整（bluetoothctl / hcitool（已弃用）/ btmon / hciconfig）。做 BLE 网关、Linux 上位机、树莓派项目基本就是它。缺点是 D-Bus API 偏复杂、版本行为差异大、文档分散。
• 适合谁：嵌入式 Linux 网关、树莓派、Android/Linux 上位机、需要"中央设备"扫描连接一堆外设的场景。

2.5 其他值得知道的

• Bluedroid / Fluoride：Android 的蓝牙栈（Apache 2.0），做 Android 定制或改机才会碰。
• Apache Mynewt：NimBLE 的母项目，一整套 RTOS，NimBLE 是其蓝牙组件。
• Zephyr Controller（sdc / openisa）：Nordic 还提供闭源的 SoftDevice Controller 供 Zephyr 搭配，性能更优但非开源——提醒你"用 Zephyr 不等于全链路都开源"。
• 芯片原厂闭源栈：Nordic SoftDevice、TI BLE-Stack、乐鑫 Bluedroid 等，是二进制黑盒或源码受限，这里不展开。

三、横向对比一张表

四、按场景怎么选（一句话结论）

• nRF52 / ESP32 做低功耗终端，要小体积 + 商用友好 → NimBLE（ESP32 用 esp-nimble）。
• 新立项、想要功能最全 + SIG 认证省事、能吃下 RTOS 学习成本 → Zephyr。
• 要做经典蓝牙音频（A2DP/HFP），或裸机无 OS，愿为省心买授权 → BTstack。
• 嵌入式 Linux 网关 / 树莓派 / 上位机做中央设备 → BlueZ。
• 只是想在 PC 上快速验证协议交互 → 直接用 BlueZ（Linux）或厂商 Dongle + nRF Connect，不必自己移植。

五、几条实战坑与建议

1. 先想清你要 Host 还是全栈：BTstack / BlueZ 只有 Host，你的芯片必须自带 Controller（或外接），否则连不起来。
2. 许可证要在立项时算清账：GPL 静态链进固件会传染；BlueZ 走 D-Bus 进程隔离通常安全；要闭源静态链接就选 Apache 2.0 的 NimBLE / Zephyr，或买 BTstack 商业授权。别等产品做完才发现要开源。
3. "用了 Apache 栈 ≠ 全链路开源"：Zephyr 常搭配 Nordic 闭源 SoftDevice Controller；NimBLE 在某些芯片上也可能配闭源 Controller。开源的是 Host，Controller 未必。
4. 认证能省则省：Zephyr 的 SIG Qualified 设计可继承，能显著降低你的产品认证成本；自己从零移植的栈要自行走 SIG 流程。
5. 别低估构建系统门槛：Zephyr 的 west / Kconfig / devicetree 对新人不友好，评估工期时把学习成本算进去。
6. 国产芯片选栈看移植生态：很多国产 BLE 芯片（如沁恒 CH58x、部分 RISC-V 蓝牙芯片）会提供 Zephyr 或 NimBLE 的移植分支，优先复用原厂/社区已移植版本，别自己从头啃 HCI 适配。

一句话收尾：资源紧、要商用闭源选 NimBLE；押长期、要全功能选 Zephyr；做经典蓝牙音频或裸机选 BTstack；上 Linux 网关选 BlueZ。 四者定位互不重叠，先定"跑在什么硬件、要不要闭源、要不要经典蓝牙"这三个问题，答案基本就出来了。