为什么汽车和工业现场都用 CAN，而不是 UART、SPI、I2C？本文以 STM32F103 + TJA1050 双机通信为例，从硬件接线、位时序计算、过滤器配置，到三邮箱发送、FIFO 中断接收逐段拆解，附 6 条避坑清单。

同样是掉电保存，AT24C02 只有 256 字节，W25Q64 却给到 8MB。SPI 看似只有四根线，模式 0 时序、指令帧格式、页编程、扇区擦除，处处有讲究。本文用案例拆解 STM32F103 SPI1 + W25Q64 完整流程：初始化、擦除、读写、状态轮询，附 6 条避坑清单。

调试记录仪参数掉电就丢？校准值每次上电都要重设？I2C 只有两根线，却让无数嵌入式开发者卡在起始条件、应答等待和 BUSY 死锁上。本文用一个成熟案例——STM32F103 硬件 I2C1 + AT24C02 读写全流程，拆解从总线时序到 SPL 事件等待的每一个细节，并附上 6 条实战避坑清单。

先看三种接收方式的对比。轮询接收：主循环死等 RXNE 标志。逻辑简单，但接收期间 CPU 啥也干不了。数据一多，系统直接卡死。逐字节中断：每来一个字节触发一次 RXNE 中断。115200 波特率下，每字节约 87µs 进一次中断。CPU 被高频打断，还要自己拼帧、判断帧尾。数据量一大，中断开销直接吃掉大半 CPU。DMA + IDLE：DMA 在后台把字节自动搬进内存，CPU 全程不参与。总线

上电后到第一个任务运行，STM32 到底经历了什么？从硬件自动装载向量表，到 uC/OS-II 第一个任务开始运行，中间隔着整条控制权交接链。本文逐层拆解：MSP/PC 从哪来、main 之前谁在干活、第一个任务如何从栈帧里"复活"。

前 9 篇，系统是跑在单机上的：一个 TDengine 容器，REPLICA 1，数据只有一份。节点挂了，数据还在盘上，但服务没了。这一篇把部署换成三节点集群，REPLICA 3，然后真的停掉一个节点做故障演练——看看查询还能不能继续。这也是本系列最后一篇：从部署到高可用，一条遥测数据的旅程完整闭环。

第 7 篇的模拟器里，电机设备的振动超过 0.18 就报状态码 2、超过 0.35 报 3——但这两个阈值是写死在模拟器里的。真实系统不能这样：阈值得能配、能停用、能按设备类型区分。这篇讲告警引擎：规则存 PostgreSQL，遥测在 TDengine，evaluate 实时跨库求值，一条规则从创建到触发的完整旅程。

档案放 PostgreSQL，时序放 TDengine——这是很多 IoT 系统的标准姿势。但真要把两个数据源塞进同一个 Spring Boot 应用，配置、注入、防注入、分页、健康检查，每一步都有坑。本文用实战源码，讲透双数据源查询层的完整实现。

第 4 篇我们搭好了写入管线，背压、攒批、并发 worker 都就位了。可管线再高效，也得有数据往里喂。今天回到源头：数据从哪来？两条路——模拟器直接造，采集器从三源收，最终都汇入同一条 pipeline。这篇就讲四件事：物理模型、确定性 seed、归一化漏斗、坏数据去向。读完你能回答：模拟器的物理模型为什么这么设计？三源各适合什么场景？坏数据去哪了？

同一个数据库，三种进门方式：WebSocket 走 6041、REST 也走 6041、Native 独占 6030。端口背后藏着协议实现的本质差异。读懂这里，你才能写出公平的基准测试，也才知道日常开发该走哪扇门。