GATT系列前六篇我们一直站在客户端的视角看 GATT：先发现地图，再按图取值，然后分七个可靠等级把值写回去。所有动作都由客户端发起，服务器始终是一个被提问的角色。但真实设备上有大量数据根本等不及客户端来问：心率带每秒要报新采样，手表固件传输时要不断回送接收进度，服务表发生变化时要主动提醒所有绑定手机。这一篇把方向彻底倒过来，看服务器如何不请自来地推送。目录一、推送之前先装开关：性质位与 CCCD二、三种推送报文的全景三、单条通知：0x1B，发后即忘的下行通道四、空口实录一：467 条通知撑起的双向会话五、多值变长通知：0x1F，一条报文打包多个特征六、指示：0x1D 加 0x1E，点名必须答到七、通知还是指示：一个可靠性加价的选择题八、全系列收束之一：GATT 过程到 ATT opcode 的全景总表九、全系列收束之二：30 秒事务超时与承载的死亡十、全系列收官：一张地图、三条通道、一条红线十一、测验推送只有两种正式机制：通知（Notification）和指示（Indication）。前者发后即忘，后者必须等到客户端的确认。围绕这两种机制，这一篇还要完成整个系列的两次收束：把全部 GATT 过程到 ATT opcode 的映射总表串讲一遍，它是日后查任何报文的一页式索引；再讲透 30 秒 ATT 事务超时这条所有请求类过程共同的红线。老规矩，所有结论都拉到一份真实空口上。这份抓包记录的是一次 Central 手机给 Peripheral 手表传输表盘资源的 OTA 过程，恰好又是一个速率问题的现场，推送通道在里面留下了 467 条通知和一个有意思的未解码 opcode。先看一个最直观的现场。传输开始前，手机往订阅描述符写入 0x0001，打开通知开关；31.1 毫秒后，手表方向的第一条 Handle Value Notification 就到了，载荷 12 字节。客户端什么都没问，数据自己上门——整个推送家族的故事就从这 31 毫秒开始。一、推送之前先装开关：性质位