前面讲过 GATT Service 里有一个叫 Database Hash 的特征，值是 16 字节，客户端拿它当服务表的指纹。一旦指纹变了，就说明服务器的服务定义改了，客户端得重新发现。但这个指纹具体怎么算？哪些属性参与、哪些不参与？字节怎么拼？规范 用一个完整的示例把这件事讲透了。目录一、计算流程总览二、拼接规则：哪些字段进 m三、逐步拆解示例属性表四、AES-CMAC 取摘要五、空口：Database Hash 特征真实存在六、工程启示：Hash 计算的边界条件七、测验它是 GATT 安全缓存机制的底层支撑。搞懂了 Hash 的计算，就能理解为什么 Robust Caching 能准确检测服务变更，为什么客户端敢缓存发现结果。一、计算流程总览Database Hash 的计算分三步：先把属性表按句柄升序排列，然后按规则挑出部分属性的部分字段拼接成一条变长消息 m，最后用 AES-CMAC 对 m 取 128 位摘要。规范：Table B.1 shows how the variable length data m for calculating the Database Hash is constru