在低功耗蓝牙（BLE）通信中，服务发现是所有GATT（通用属性协议）交互的前提。无论是智能手环传输心率数据、蓝牙键盘发送按键指令，还是智能家居设备上报状态，主机（如手机、电脑）都必须先通过服务发现流程，找到从机（如手环、键盘）提供的服务、特征及属性，才能建立后续的数据传输链路。从协议栈分层来看，服务发现的核心逻辑由ATT（属性协议）实现——ATT定义了属性的格式、读写规则及发现方法；而GATT则基于ATT，将属性组织为服务-特征-描述符的层级结构（如HID服务包含Report特征、HID Information特征）。但ATT报文并非直接在主机与从机之间传输，而是通过HCI（主机控制器接口）封装为数据报文，由控制器（蓝牙芯片）完成射频层的发送与接收。因此，从HCI视角分析ATT报文的交互过程，具有极强的实战价值：对开发工程师：可通过HCI抓包定位服务发现失败问题（如特征未找到、句柄范围错误）；对测试工程师：能验证设备是否符合BLE协议规范（如服务UUID是否正确、特征属性是否匹配）；对技术学习者：可深入理解主机如何一步步识别从机能力的底层逻辑，而非仅停留在GATT的抽象概念。本文将基于BLE服务发现相关ATT报文（含Find By Type Value、Read By Group Type、Read By Type等命令），从HCI视角完整拆解服务发现的全流程，详细解析每类报文的格式、参数含义、响应逻辑及在流程中的作用，并结合实战场景说明异常响应（如ATT Error Response）的原因，最终形成理论+实例的完整分析体系。目录一、基础认知：BLE协议栈中的ATT、GATT与HCI1.1 协议栈分层：ATT与GATT的依赖关系1.2 ATT核心概念：服务发现的基本元素1.3 HCI与ATT的关联：数据报文的封装与传输二、核心流程拆解：基于ATT报文的BLE服务发现全阶段2.1 阶段1：初始服务扫描——定位核心服务的句柄范围2.2 阶段2：特征声明发现——遍历服务下的特征，确定特征属性与句柄2.3 阶段3：属性详情查询——Find Information Request确认属性UUID与描述符2.4 阶段4：具体属性读取——Read Request获取服务/特征的实际值2.5 阶段5：异步通信配置——Write Request设置CCCD，启用通知/指示三、基于HCI-ATT报文的问题排查与协议验证3.1 问题排查：从ATT报文定位服务发现失败原因3.2 协议验证：确认设备是否符合BLE规范四、BLE服务发现的逻辑链条与HCI视角的核心价值4.1 服务发现的完整逻辑链条4.2 HCI视角的核心价值一、基础认知：BLE协议栈中的ATT、GATT与HCI在拆解流程前，需先明确ATT、GATT、HCI三者的关系及核心概念——这是理解后续报文交互的语法基础。1.1 协议栈分层：ATT与GATT的依赖关系BLE协议栈中，ATT（Attribute Protocol）位于L2CAP层之上，GATT（Generic Attribute Profile）基于ATT实现，三者的层级与职责如下：