发现流程走完，属性表的地图已经在客户端内存里铺开了：哪个服务占哪段句柄、每个特征的声明句柄和值句柄分别是多少、后面挂着哪些描述符。但地图不等于货物。真正要拿到温度、电量、设备名这些业务数据，客户端还得主动开口向服务器要——这就是读（Read）类过程要解决的问题。
目录
一、全景图：七个读子过程，底层只有四条原语
二、直读：给我句柄，还你值
三、空口实录一：一次被拒绝的直读与 iPhone 的降级走位
四、按 UUID 读：不知道句柄时的拿货方式
五、空口实录二：两次读设备名，26 字节载荷逐字节拆
六、长值读：首包 Read 打头，Blob 翻页收尾
七、一次读多个：定长拼接与变长元组的字节级差异
八、读描述符：没有新原语，只有新语义
九、空口实录三：写后 90 毫秒回读 CCCD
十、选型决策与几个工程细节
十一、测验
这一篇把 GATT 读家族一次性讲透：特征值读的五个子过程，加上描述符读的两个子过程。七个名字听着多，底层其实只有四条 ATT 原语在反复组合。老规矩，不空谈定义，每一种读法都用 iPhone 连手表的真实空口做现场验证——直读被拒绝怎么收场、只知 UUID 不知句柄怎么拿货、写完 CCCD 为什么还要回读一次，空口里全有。
一、全景图：七个读子过程，底层只有四条原语
先把地图立起来。读家族的知识体系用一张表就能收住：
