直接reinterpret_cast将float地址转char*逐字节读取可能触发未定义行为，因编译器优化导致读取异常；memcpy是安全跨平台方案，不违反严格别名规则且保留原始字节序。
直接 reinterpret_cast 会出什么问题
把 float 变量地址强转成 char* 指针再逐字节读取，看似最直白，但极易触发未定义行为（UB）——尤其当原变量是局部栈变量且未对齐时。C++ 标准禁止通过非字符类型指针访问对象，除非用 char* 或 unsigned char*；但反过来，用 reinterpret_cast<char>(&f)</char> 是允许的，前提是后续只做字节级读写，不 reinterpret 回其他类型。
常见错误现象：memcpy 正常、reinterpret_cast 在开启 -O2 后读出全零或随机值，本质是编译器做了非法优化（如认为该内存未被修改而复用寄存器值）。
- 安全用法仅限：取地址 → 转
const unsigned char*→ 逐字节拷贝或打印 - 禁止：转成
int*或uint32_t*再解引用（哪怕只是读） - 结构体字段若含
float，其偏移受对齐影响，不能假设第 0 字节就是 float 的首字节
memcpy 是更稳妥的跨平台方案
memcpy 不触发严格别名规则（strict aliasing），编译器明确知道你在做字节搬运，不会乱优化。它也是标准库中唯一被保证能正确处理任意类型底层表示的函数。
使用场景：序列化到网络包、写入二进制文件、与硬件寄存器交互等需要确定字节顺序和布局的场合。
立即学习“C++免费学习笔记（深入）”；
- 必须确保目标缓冲区至少有
sizeof(float)字节（通常是 4） - 源地址必须有效，且生命周期覆盖 memcpy 执行期
- 不需要手动处理大小端——memcpy 搬运的是内存中的原始字节序，即当前平台 native order
示例：
float f = 3.14159f;
std::array<unsigned char, 4> bytes{};
memcpy(bytes.data(), &f, sizeof(f)); // 安全、可预测、无 UBfloat 到字节数组的两种典型需求差异
你真正要的不是“转成字节数组”，而是“按某种语义解释这 4 个字节”——这点决定选哪种方式。
- 要保留 IEEE 754 布局且兼容其他系统（如 Python struct.unpack）→ 用
memcpy+ 显式检查std::endian::native，必要时手动翻转字节 - 仅在本机调试查看 bit pattern（比如验证 NaN/Inf 编码）→
reinterpret_cast<const unsigned char>(&f)</const>可读，但别用于赋值或传参给非 char* 函数 - 嵌入式驱动中向 uint8_t[4] 寄存器写 float 值 → 必须用
memcpy，否则某些 ARM Cortex-M 编译器会插入非法指令
别忽略浮点数的特殊值和对齐要求
IEEE 754 的 NaN、Inf、负零在内存中都有特定 bit 模式，memcpy 和 reinterpret_cast 都能原样保留；但如果你用 union（比如 union { float f; uint32_t i; }），在 C++17 后虽允许 active member 切换，仍需确保 union 实例本身满足 alignof(float)（通常为 4，但某些平台或 packed 结构里可能不满足）。
- 局部变量一般自动对齐，但
malloc返回的内存不一定对齐 float —— 用aligned_alloc(4, sizeof(float))或std::vector<:byte></:byte>更可靠 - 结构体中 float 成员前若有 char 成员，编译器可能插入 padding，
offsetof(MyStruct, f)才是真实偏移 - 不要依赖
sizeof(float) == 4—— 虽然几乎所有主流平台都是，但标准只要求 ≥ 4，极端环境（如某些 DSP）可能不同
真正麻烦的从来不是怎么搬字节，而是搬完之后——你是否清楚这 4 个字节在目标环境里会被如何解释。
