1. 蓝牙技术基础：从1.0到5.4，我们到底在用什么？

各位同学好，我是老周。做蓝牙网关这些年，我见过太多人一上来就追着问“网关怎么配”，结果连蓝牙版本都搞不清楚。说实话，蓝牙技术发展了二十多年，版本号从1.0一路跑到5.4，中间的变化可不是简单的数字游戏。今天咱们就把这块地基打牢。

蓝牙1.0是1999年推出的。那时候我还在学校，压根没接触过。真正让我印象深刻的，是蓝牙2.0 + EDR。2004年，EDR（增强数据率）把速率提到了3Mbps。我当时做第一个蓝牙项目，用的就是2.0芯片。嗯，那个项目最后因为干扰问题差点黄了——蓝牙和Wi-Fi在2.4GHz频段打架，老问题了。

后来蓝牙3.0 + HS（高速）在2009年出现，它其实是个“混血儿”：蓝牙负责握手，数据走Wi-Fi。想法很好，但实际用的人不多。为什么？功耗高，而且协议切换太慢。

真正改变行业的是蓝牙4.0。2010年，低功耗蓝牙（BLE）诞生了。我清楚记得第一次用BLE芯片做传感器节点，一颗纽扣电池跑了半年。从那以后，经典蓝牙和低功耗蓝牙就分家了。

蓝牙5.0（2016年）带来了4倍距离、2倍速度、8倍广播容量。5.1（2019年）加入了方向定位，5.2（2020年）引入了LE Audio，5.3（2021年）优化了功耗和连接稳定性，5.4（2023年）则进一步增强了广播安全和周期性广播。

核心要点：蓝牙版本向下兼容，但功能差异巨大。做网关选型时，千万别只看“支持蓝牙”三个字，一定要确认具体版本和特性。

很多人问我：“老周，BLE是不是比经典蓝牙好？”我的回答是：看场景。

经典蓝牙（BR/EDR）适合持续传输、高吞吐量的场景，比如蓝牙耳机、音箱、文件传输。它的连接是持续的，功耗也高。

低功耗蓝牙（BLE）适合间歇性、小数据量、低功耗的场景，比如传感器、信标、健康设备。它的连接是事件驱动的，大部分时间在睡觉。

我的经验：做蓝牙网关时，大部分场景用BLE就够了。但如果你要传音频或大文件，别犹豫，上经典蓝牙。我曾经在一个项目中硬用BLE传音频，结果延迟大到没法用，最后全盘重来。

蓝牙协议栈是个分层结构。说白了，每一层只干自己的事，把复杂的东西封装起来。你想想看，如果所有功能都揉在一起，改一个地方全崩，那谁受得了？

我习惯把协议栈分成三块：控制器、主机、应用层。控制器负责射频和底层链路，主机负责逻辑链路和属性协议，应用层就是咱们写代码的地方。

这张图我画了很多次。你看，从上到下依次是：应用层、主机、HCI接口、控制器。HCI是主机和控制器之间的“翻译官”。实际开发中，如果你用单芯片方案（比如Nordic、TI的SoC），HCI是内部走的，你基本感觉不到。但如果你用双芯片方案（比如手机+蓝牙芯片），HCI就是串口或USB，你得自己处理。

咱们挑几个重点说说：

GAP（通用访问配置文件）：负责设备发现、连接建立、广播。说白了，就是让两个设备能“看见”对方并“握手”。
GATT（通用属性配置文件）：定义了数据怎么组织和交换。BLE世界里，所有数据都是“属性”，通过服务（Service）和特征（Characteristic）来管理。
L2CAP（逻辑链路控制与适配协议）：负责数据分包和重组。经典蓝牙和BLE的L2CAP不太一样，注意区分。
SM（安全管理）：负责配对、绑定、加密。我遇到过不少开发者在这里翻车，配对失败、密钥丢失，都是常见坑。

避坑指南：我曾经在一个网关项目中，因为没处理好GATT的MTU（最大传输单元）协商，导致数据分包错误，设备频繁断连。后来花了三天才定位到问题。记住：BLE默认MTU是23字节，实际可用只有20字节。如果你要传大包，一定要在连接后协商MTU。

经典蓝牙的协议栈比BLE复杂得多。它多了RFCOMM（串口仿真）、SDP（服务发现协议）、AVDTP（音视频分发）等。而BLE的协议栈更精简，去掉了这些“重”协议，换成了轻量的ATT/GATT。

你看，经典蓝牙的协议栈像个“瑞士军刀”，什么都能干，但重。BLE像个“手术刀”，专精于低功耗、小数据、快速连接。做网关时，我建议你根据终端设备类型来选择。如果终端是传感器，BLE是首选；如果是音频设备，经典蓝牙跑不掉。

这一章我们聊了蓝牙从1.0到5.4的演进，经典蓝牙和BLE的区别，以及协议栈的分层架构。说实话，这些概念看起来枯燥，但它们是后续所有章节的基石。你想想看，如果连GATT和GAP都分不清，后面怎么理解网关的数据转发和连接管理？

我个人习惯是，每接触一个新蓝牙芯片，第一件事就是看它的协议栈支持列表。支持BLE 5.2吗？支持LE Audio吗？支持Mesh吗？这些信息直接决定了你的网关能做什么、不能做什么。