PlatformIO 生产落地案例
五、生产落地案例
案例一：统一多产品线的构建入口
业务背景：一家做智能硬件的公司有两条产品线，一条基于 ESP32，一条基于 STM32，两边各用一套 IDE 与各自的构建脚本，代码共享靠人工复制，经常出现「改了 A 忘了 B」。
怎么用：把公共业务逻辑抽成独立目录，通过 lib_extra_dirs 或本地库依赖共享；两个产品线各写一个 env，共用 [env] 基段里的编译参数与库依赖；硬件差异用 build_flags 里的宏区分，业务代码里用条件编译处理；CI 里两个环境都编译，任何一个失败都拦下来。
关键配置：平台与库版本全部锁定到具体版本；构建缓存目录在 CI 里做缓存以缩短时间；把 platformio.ini 与代码一起评审，避免有人随手改了编译宏。
效果指标：两条产品线共享代码的改动只需改一处；「本地能编译、CI 不能编译」的情况基本消失；构建从「各自 IDE 点按钮」变成可脚本化的一步。
踩过的坑：一是依赖用了模糊版本，某个上游库更新后构建直接失败，改成锁定版本；二是平台包版本不一致，不同人机器上的工具链版本不同导致行为差异，后来在配置里显式指定平台版本；三是把所有代码塞进一个 src 目录，条件编译的 #if 遍布全文件，可读性很差，后来按产品线拆目录并用 build_src_filter 筛选。
案例二：用真板单元测试拦住回归
业务背景：一个工业采集设备的固件，每次发版前靠人工按清单点一遍功能，耗时且容易漏，尤其是一些异常路径（传感器掉线、通信超时）根本没法靠手工稳定复现。
怎么用：用 pio test 写基于 Unity 的测试，把可测的逻辑（协议解析、校验算法、状态机迁移、超时判定）从硬件访问中抽出来，通过接口替换在测试里注入模拟数据；测试跑在真板上，用串口输出结果；把 pio test 加进发版前的检查清单。
关键配置：测试目录结构按框架约定组织；用 test_filter 分组，让不同测试集可以在不同环境跑；对涉及硬件外设的测试，提供烧录前的手动接线说明。
效果指标：发版前的人工验证时间明显缩短；异常路径第一次有了稳定的复现手段；回归问题在提交阶段就被拦住。
踩过的坑：一是一开始就试图测全部，包括强依赖硬件的部分，维护成本失控，后来只测纯逻辑部分；二是测试之间互相干扰（共用全局状态），必须保证每个测试独立初始化；三是没接进流程，测试写了但没人跑，加进 CI 与发版清单后才真正起作用。
