在一次 OpenHarmony 设备联调中，我们为约 2KB 的物模型响应增加了 CoAP 分块传输，并修复了重组后的业务回调问题。单次查询能够完成，但随后出现了一个回归：中枢控制子设备，开始几次正常，多操作几次就可能立即失败，过一会儿又恢复。 故障最终定位到客户端的资源保护逻辑。为避免并发请求覆盖分块状态，代码把请求快照保存在整个 endpoint 共享的位置，并在该位置被占用时拒绝新请求。结果

小型化设备接入本地中枢时，需要完成激活、设备信息同步、状态上报和心跳。产品可能使用 TLS/TCP，也可能使用 DTLS/UDP。业务流程基本相同，底层连接方式却存在实质差异。 直接复制两套业务代码，容易让修复和功能演进产生分歧；在每个业务函数中增加 TLS/DTLS 分支，又会让状态机与网络细节纠缠在一起。对 RAM、Flash、任务栈和调度资源都有限的设备，这些重复实现和模糊的资源归属最终会影

一台设备已经连上 Wi-Fi，配置器也收到了“入网成功”，为什么本地中枢里仍然看不到它？ 在 BLE+Wi-Fi Combo 终端上，这个现象并不矛盾。BLE 负责把设备带入网络，Wi-Fi 提供网络连通性，终端还要找到正确的中枢、完成安全认证、激活和状态同步，才能真正进入业务在线状态。排查这类问题，关键是看清每一步交给下一步的是什么，以及下一步有没有接住。 本文以 OpenHarmony 统一互

一、为什么要区分 BLE 直连与 BLE+Wi-Fi Combo 统一互联 3.0 的应用终端可以采用不同的网络形态，但首次配网通常都从近端 BLE 开始。BLE 的职责是让配置对端发现设备、建立安全会话、完成设备认证并下发长期配置；它并不天然等同于设备后续的运行期网络。 本文以 WS63 应用终端为例，整理两种常见形态： 两种形态不能被理解为“两套完全独立的协议”。它们的前半段应尽可能复用同一套

WS63 LittleFS 挂载失败与分区 ID 排查 一、问题背景 WS63 Combo Demo 会将 iot_connect 的配置与认证初始化数据保存到 LittleFS。若底层文件系统未正确挂载，Demo 即使 BLE 已广播，也可能在安全服务启动或创建配置目录时失败，典型日志为： lfs_mount failed, ret = ... 这个现象不能直接等同于“/iotc 路径写错”。应