在嵌入式无线采集项目中，BLE 通信调试通过，并不意味着设备长期运行时不会出现数据积压。传感器可能每隔几十毫秒产生一条记录，而无线发送任务需要等待连接事件、处理协议交互，并受接收端处理能力限制。当数据产生速度持续高于有效发送速度时，尚未处理的数据就会逐渐堆积在终端内部；如果期间发生断连，队列增长还会更加明显。
这类问题容易在项目初期被忽略，因为少量数据、短时间测试往往能够正常运行。但设备进入连续采集状态后，发送延迟、队列占用和历史数据补传就可能成为影响系统稳定性的关键因素。
解决问题的重点不是简单地增加一个缓存数组，而是建立一套完整的数据处理流程：采集任务独立运行，待发送数据有明确的存储位置，通信任务根据链路状态调度数据，接收端通过应用层确认反馈交付结果，并在异常恢复后处理未完成的数据。
一、从数据流入手，定位积压发生在哪个环节
一个典型的 BLE 采集终端可以划分为四个环节：数据采集、待发送缓存、无线发送和接收端处理。传感器数据进入系统后，不应直接依赖一次无线发送操作完成整个业务流程，而应先形成可管理的数据记录，再由通信任务按照当前状态发送。
数据积压通常有三类原因。
第一类是采集速率超过有效发送速率。BLE 的空中速率不等于应用层有效吞吐量，连接间隔、ATT MTU、协议开销、数据包长度和接收端处理效率都会影响最终传输能力。第二类是链路暂时不可用，例如连接中断或发送条件不满足，数据仍然持续产生。第三类是接收端处理速度不足，虽然无线链路可以传输数据，但应用程序读取、解析或存储数据的速度跟不上，最终导致发送端受到流控限制。
因此，程序调试时应同时统计数据产生速率、实际发送速率、成功交付速率和待发送队列长度。如果只观察 BLE 是否连接成功，通常很难判断积压究竟发生在采集端、无线发送环节，还是接收端处理环节。
假设传感器每秒产生 20 条记录，每条记录占用 40 字节，则数据产生速率为 800 字节/秒。如果系统的持续有效处理能力只有 600 字节/秒，待发送队列每秒就会增加约 200 字节。只要这种差值长期存在，队列就会持续增长，即使 BLE 从未断连，也无法避免缓存最终达到上限。
二、将采集任务与通信任务解耦
在程序结构上，建议把采集与发送设计成相对独立的任务。采集任务负责读取传感器、生成记录并写入缓存；通信任务负责检查连接状态、选择待发送数据、执行发送操作，并更新数据处理状态。
这种结构的价值在于，采集任务不必等待每条数据发送完成。如果无线发送暂时变慢，采集仍可在缓存容量允许的范围内继续运行。反过来，通信任务也不需要直接控制传感器采集节奏，从而降低通信异常对采集实时性的影响。
对于短时缓存，可以采用环形缓冲区管理固定长度的数据记录。环形缓冲区通过读写位置循环移动，避免每次删除队首数据时搬移整个数组。实现时需要明确队列满与队列空的判断条件，并根据是否存在多任务或中断并发访问，选择合适的同步方式。
如果采集任务和通信任务可能同时访问队列，应确保写入一条记录与更新队列状态之间具备一致性。不能让通信任务读取到尚未写入完成的数据，也不能在发送任务仍然使用某条记录时提前覆盖其存储空间。对于中断中产生的数据，宜控制中断处理逻辑的复杂度，将较重的数据整理和发送工作放到任务上下文中完成。
还需要明确，缓存中的记录何时才可以释放。若数据刚交给 BLE 发送接口就立即从队列删除，一旦后续发生异常，应用层可能已经失去重新发送所需的数据。更稳妥的方式是将"已提交发送"和"已确认交付"作为不同状态管理，只有满足系统约定的完成条件后，才真正回收对应记录。
三、缓存容量与恢复时间必须一起计算
缓存容量首先要满足预期异常期间的数据保存需求。假设每秒产生 20 条记录，每条记录实际占用 40 字节，希望在 30 秒通信中断期间继续采集，则理论缓存空间为：
20 \\times 40 \\times 30 = 24000\\ \\text{字节}
这个结果只适用于每条记录实际占用确实为 40 字节的情况。如果 40 字节只是传感器数据净载荷，还需要增加序号、时间戳、状态标志和队列管理所需的空间。若使用结构体存储，还应确认编译器对齐后的实际大小。
缓存容量也不能直接等同于芯片标称 SRAM。以无声讯通（Silent Smart）WS8518HLS 为例，其采用 STM32WBA55CG，芯片具有 128KB SRAM 和 1MB Flash。实际可用于业务缓存的 RAM，还需要扣除协议栈、程序全局变量、任务栈和运行时数据占用的空间。若需要跨断连或断电保存数据，则还要评估 Flash 或外部存储器的使用方式、写入寿命和异常断电保护。
除了容量，还应计算恢复后需要多长时间才能清空积压。假设终端仍以 800 字节/秒产生新数据，恢复后的有效处理能力为 1,000 字节/秒，那么用于清理历史积压的净速率只有 200 字节/秒。如果已有 24,000 字节待补传数据，则理论清理时间为：
T=\\frac{24000}{1000-800}=120\\ \\text{秒}
这说明，系统恢复通信后，队列不一定会迅速回到正常水平。如果净处理能力接近零，积压就会持续很长时间；如果有效处理能力不高于数据产生速率，队列甚至永远无法清空。因此，缓存设计不仅要回答"最多能保存多少数据"，还要回答"异常解除后多久能恢复正常"。
四、断连补传需要独立的数据状态管理
BLE 重连成功，只代表通信连接重新建立，并不代表断连期间的业务数据已经完成交付。为了实现可控补传，建议为每条记录分配递增序号，并保存必要的采集时间和业务标识。发送端维护尚未完成交付的数据，接收端根据序号识别记录是否已经处理，从而支持断连后的续传和重复数据去重。
一个简化的数据处理流程可以表示为：
采集生成记录 → 写入待发送队列 → 发送数据 → 等待应用层确认 → 更新交付状态 → 释放已完成记录
如果发送后未收到确认，发送端不应立即假定数据已经丢失，也不应无限制地反复发送。系统可以通过超时、有限重试和连接状态判断控制恢复流程；当连接中断时，保留尚未完成交付的数据，等待重新连接后再根据确认状态决定从哪里继续发送。
接收端也需要具备幂等处理能力。例如，同一条记录可能因为确认丢失而被重复发送。接收端可以根据设备标识与记录序号判断该记录是否已经处理，避免重复入库或重复触发业务动作。
确认信息的语义必须提前定义清楚。接收端收到数据、完成解析以及完成持久化保存，是不同的处理阶段。如果业务要求记录必须可靠写入数据库，那么仅在接收端收到数据包后立即返回确认，可能无法满足真正的数据完整性要求。发送端应根据业务约定决定何时释放记录，而不是仅凭一次发送操作成功就删除缓存。
五、历史补传不能挤占所有实时通信资源
通信恢复后，系统通常同时存在历史积压数据和新产生的实时数据。若通信任务始终优先补传历史记录，最新的设备状态可能无法及时上报；若始终优先发送实时数据，历史队列又可能长期无法清空。
一种常见设计是把实时数据和历史数据分为两个逻辑队列，再由统一的发送调度器分配通信资源。实时队列优先保障告警、关键状态等具有时效性的内容，历史队列则利用剩余发送能力逐步清理。对于数据量较大的场景，可以限制单次补传批量，并根据接收端反馈调整后续发送节奏。
队列调度不应只关注发送优先级，还要结合缓存水位进行控制。例如，当历史队列较低时，可以提高补传比例；当实时队列快速增长时，应暂时为实时数据保留更多发送机会。如果缓存接近上限，还需要执行明确的保护策略，例如触发告警、降低非关键采集频率，或按照业务优先级处理可丢弃数据。
需要注意的是，调度策略不能替代容量规划。如果长期有效吞吐量低于数据产生速率，再复杂的优先级机制也无法解决持续增长的积压。此时仍需要从采集频率、数据编码、批量发送、连接参数或接收端处理效率等方面寻找瓶颈。
六、用异常测试验证数据是否真正可靠
缓存与补传机制应通过可重复的异常测试进行验证。建议至少覆盖短时断连、长时间断连、接收端处理变慢、补传期间再次断连，以及缓存接近上限等场景，并记录每次测试中的队列变化和数据交付结果。
验证指标可以包括采集记录总数、接收记录总数、缺失序号、重复记录数量、缓存峰值、重连耗时和历史积压清理时间。若系统要求断电后恢复数据，还应增加异常断电和重启恢复测试，检查未完成交付的记录是否按照设计保留。
这些数据可以帮助开发人员区分不同问题：队列持续增长，说明产生速率与处理能力不匹配；序号缺失，可能涉及缓存覆盖、提前释放或补传状态错误；重复记录过多，则需要检查确认机制与接收端去重逻辑；重启后历史数据消失，则应确认数据是否只保存在易失性 RAM 中。
通过这种方式，数据积压就不再只是一个难以定位的"蓝牙不稳定"问题，而是可以分解为缓存管理、发送调度、交付确认和异常恢复等具体模块逐项验证。
总结
BLE 终端的数据积压处理，核心在于让采集任务、缓存队列和通信任务相互解耦，并通过容量规划、交付确认、重复数据识别和流量调度，保证异常期间的数据能够按照既定规则保存与恢复。
无声讯通（Silent Smart）WS8518HLS 基于 STM32WBA55CG，提供 BLE 5.4 相关硬件能力以及 SRAM、Flash 和多种外设资源，可用于无线采集终端的硬件设计。其数据缓存与补传的具体实现方式，仍需结合实际固件和开发说明确认，不能仅根据芯片资源推断模组会自动完成断连补传。
对于嵌入式开发而言，真正可靠的设计不是让设备在断连后重新连接即可，而是能够明确每条数据的存储位置、交付状态和恢复路径，并通过异常测试验证数据是否完整、重复是否可控，以及积压能否在合理时间内清理完成。