先澄清一个容易混的点：这里的 BAS 是 Battery Service（电池服务），属于 GATT 体系下的标准服务。它的服务 UUID 是大家熟悉的 0x180F，1.1 版本在老版本只有一个电量百分比特征的基础上，把电池状态、能量、时间、健康、身份信息一整套特征补齐了。目录一、先立骨架：一个实例只伺候一块物理电池二、六种部署形态：变的是物理边界，不变的是实例归属2.1 形态一与形态二：各自独立的两套 Server2.2 形态三：分布式设备共享一个 Server2.3 形态四：可分离 + 分布式，热插拔问题的源头2.4 形态五：后买的配件，实例按需开张三、聚合组：多块电池怎么合成用户看到的一格电四、Low 与 Critical：两级告警语义五、读规范要先接受的几套规矩5.1 情态动词就是法律效力5.2 RFU 与 Prohibited：两种未知值，两种处理5.3 需求表格与一致性5.4 字节序：一律小端六、电池拔插的两条完整消息流6.1 场景一：拔下旧电池，插入一块不同的新电池6.2 场景二：拔下的是同一块电池，又插了回来6.3 三个工程上的坑七、写在最后八、测验做过 BLE 设备的同学大概率都读过电量：搜服务、找 0x2A19、读一个 0 到 100 的字节。但真正做产品时会被一连串问题打脸：TWS 两只耳机在手机上为什么有时显示两个电池、有时三个（还带充电盒）？可拆卸笔记本的底座电池拔了，服务要不要销毁？后买的背夹电池怎么动态冒出来？这篇就围绕这些问题，把 Battery Service 的设计意图、六种典型部署形态、三条术语和热插拔消息流一次性串起来。一、先立骨架：一个实例只伺候一块物理电池规范对 Battery Service 的定义只有一句话，但信息密度很高：The Battery Service exposes the Battery Level and other information for a battery (which m