为什么示例使用memcpy将uint8_t*参数转结构体而非直接强制转换

ESP8266属于32位RISC架构处理器，硬件层面默认不支持对非对齐地址执行多字节读写操作。比如你用到的unsigned long类型长度为4字节，要求其存储地址必须是4的整数倍才能直接访问，否则就会抛出LoadStoreAlignmentCause异常（对应你遇到的异常代码9）。
你遇到的崩溃就是因为TCP库传入的data缓冲区地址不满足结构体的对齐要求，强制转换后访问字段时触发了硬件异常。

memcpy的内部实现是逐字节拷贝数据，完全不要求源地址和目标地址符合对齐规则，不管传入的缓冲区地址是什么，都可以安全完成数据复制。
而示例中的incomingReadings是全局变量，其内存地址由编译器自动分配，天然满足结构体的对齐要求，把数据拷贝到这个地址后再访问字段，就完全规避了对齐风险。这种写法兼容性极强，不需要依赖库返回的缓冲区的对齐属性，跨平台、换不同通信库都不会出现对齐类崩溃问题。

大概率会崩溃。
这个问题和你在TCP库遇到的问题本质完全相同：ESP-NOW库返回的incomingData缓冲区地址不受你控制，无法保证刚好匹配struct_message的对齐要求，只要地址未对齐，访问结构体字段时就会触发同样的对齐异常。

你测试中用到的__attribute__((packed))方案生效的原因是：加了这个属性后，编译器会自动为该结构体的字段访问生成非对齐访问的兼容指令，通过逐字节读写的方式访问字段，不需要依赖地址对齐，缺点是字段访问的性能会有小幅下降，大多数嵌入式场景下该性能损失可忽略。

内容的提问来源于stack exchange，提问作者Damn Vegetables