BLE广播载荷：在传统广播与扫描响应中安排设备身份
外设成功开启广播，却不出现在产品App中，原因可能是载荷约定发生变化：App按服务UUID过滤，固件却把它移到扫描响应；或者App坚持要求完整名称，而名称已经放不下。解决这类问题，应先规定首次广播必须携带什么，再安排字节预算。
涉及产品资格声明时，应核对SIG的Core 6.0页面及强制更新；本文不是合规检查清单。
适用范围：本文针对传统、非定向、可扫描的BLE广播，广播数据与扫描响应数据分别拥有31字节容量。规范基线选用Bluetooth Core 6.0、补充规范第15版（2026年5月5日）；SDK示例限定Zephyr 3.7.0。这些是明确选择的参考版本，不代表最新版本。资料核查于2026年10月11日完成，文中硬件验证步骤尚未执行。
先确定兼容边界
蓝牙SIG的LE入门资料区分传统与扩展广播容量。扩展广播空间更大，不代表现有传统扫描器就能接收。仅为容纳长名称而切换广播方式之前，应列明控制器、协议栈和接收应用的实际支持能力。
广播内容与GATT数据库也需要分开审查。Nordic的服务与特征课程解释了GATT结构；实现服务本身，并不说明广播构造器已经携带相应UUID。服务实现与连接前发现约定，应分别形成可核查记录。
按完整AD结构计算
每个AD结构由一字节长度、一字节类型及数据组成。长度字段包含类型与数据，不包含长度字节自身；因此N字节数据实际占N加2字节。依据是Core 6.0 GAP第11节。只计算名称或UUID本体，会漏掉结构开销。
下面是一份原创容量示例，并非可以直接部署的设备身份。厂家字段仅展示长度，不提供或虚构已分配公司标识。
- Flags数据一字节，加长度与类型后占三字节。
- 一个128位服务UUID占十六字节，加结构开销后占十八字节。
- 厂家数据含两字节公司标识及六字节产品信息，加结构开销后占十字节。
- 广播合计三加十八加十，正好三十一字节。
六字节产品信息可以设计为格式版本、产品类别、配网标志各一字节，以及三字节显示标签；碰撞与隐私问题仍需另外评估。扫描响应放入十二字节ASCII名称“EnvSensor-7A”，整个名称结构占十四字节，余下十七字节。扫描响应的剩余空间不能补偿广播数据超长。
让字段类型准确表达内容
补充规范第15版（2026年5月5日）A部分区分完整与缩短名称、完整与不完整服务列表，并规定厂家数据前两字节为公司标识。缩短名称应保留完整名称的连续前缀，不能截短后仍标为完整名称，也不能把部分服务列表标为完整。
名称应按UTF-8字节计数，不能只限制显示字符数。多语言用户名称即使字符不多，也可能超过预算。允许缩短时，要停在有效字符边界，并使用缩短名称类型。不要为了节约十四字节而借用不符合实际业务的标准十六位服务UUID。
扫描响应承担补充信息
被动扫描不会请求额外信息，主动扫描才可能向可扫描广播设备请求扫描响应，见Core 6.0链路层第4.4.3节。它是独立交换过程，因此首次筛选需要的条件宜放在广播本身。
按照示例，App先凭服务UUID识别候选设备，可以暂时显示产品类别，再用后来获得的名称完善界面。缺少扫描响应不应直接丢弃合格候选。名称和短标签也不能证明设备真实性；可信身份需要由连接与应用安全机制建立。
检查SDK最终发出的内容
Zephyr 3.7.0 GAP接口的bt_le_adv_start分别接收广播与扫描响应数组，长度参数表示数组元素数，而非序列化字节数。该版本已弃用的自动名称选项可能把名称放在扫描响应末尾，空间不足时进行缩短。显式构造字段更容易审查实际布局。
建议对两个数组分别做构建期容量断言，再检查序列化输出与广播启动返回值。编译成功不等于控制器接受了配置。运行时改名也要重新核对预算；过去能容纳的字符串不能证明新名称同样安全。扫描工具可能合并展示两种报告，取证时应保留原始字段来源。
按字节边界与接收假设验收
- 构造正好三十一字节的广播，再增加一字节产品信息。构造器应在启动前拒绝三十二字节结果。
- 逐个核查AD长度与剩余缓冲区；越界结构应拒绝，固定长度字段尾部的零填充另行处理。
- 测试空名、短名、边界名称和多语言名称，检查类型与编码边界是否正确。
- 在获准测试的硬件上分别捕获广播与扫描响应，并比较主动和被动扫描。
- 用已保存字节样本验证生产App过滤器，覆盖名称缺失、延后与缩短，确认首次发现仍符合约定。
- 交付协议字段表，记录类型、所在报文、字节序、最大长度、版本及缺失或未知字段处理。
本文容量算术可在本地核对，空口接收和手机兼容性必须实测。发布前应确认固件与App对首次广播的必要字段一致，并能稳定拒绝超长或损坏结构。这样一次显示名称调整，才不会意外变成设备发现故障。
