前面讲过 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
