修改了一段 C++ 代码，编译没有报错，设备上的行为却没有变化。遇到这种情况，很容易先怀疑缓存，再重新编译整个系统。但如果改动没有进入当前产品的构建链路，重复编译只会再次得到相同结果。 阅读 Laval 社区的编译构建、clangd 配置和产物命名文章后，我把这个问题整理成五个连续的检查点：改的是哪份源码，文件属于哪个目标，实际使用什么编译参数，更新了哪个产物，运行时是否执行到新代码。 本文面向使

1. 为什么“编译成功”仍可能烧出错误镜像 OpenHarmony 设备开发中，经常出现一种看似矛盾的现象：源码已经修改，完整构建也输出 build success，烧录后板端却仍表现为旧问题。 原因通常不在编译器，而在交付链路： 源码 -> GN/Ninja 中间产物 -> kernel / rootfs / FIT -> 产品 OUT -> Windows 烧录目录 -

1. 目标与调用链 本文介绍在 OpenHarmony 5.1 小型系统中，把 iot-management 的设备发现和连接能力接到 WS73 Wi-Fi 的实践方法。 最终调用链可以概括为： iot-management -> OpenHarmony Wi-Fi C API -> Wi-Fi Manager / HAL -> WPA + nl80211 -> cfg80

1. 问题背景 本文记录一次 OpenHarmony 5.1 小型系统在 Hi3516CV610 平台集成 WS73 Wi-Fi/蓝牙模组的完整定位过程。目标不是只让三个内核模块完成编译，而是让最终烧录镜像能够在冷启动和热重启后稳定完成以下链路： SDIO 控制器初始化；WS73 设备枚举；平台、Wi-Fi、蓝牙模块加载；主固件和校准固件下载；创建 wlan0、p2p0 等运行时接口。 这类问题的