std::bit_cast仅在源与目标类型大小严格相等且均为trivially_copyable时合法，否则编译失败；常见错误包括大小不等、非trivially_copyable类型或含cv限定符。
它只在源和目标类型大小严格相等、且都为 trivially_copyable 时才合法；否则编译失败，不是运行时报错，也不是静默 UB —— 这是它和 reinterpret_cast 的根本区别。
std::bit_cast 编译直接失败的常见原因
你写完代码却连编译都过不了？大概率踩中了这两条硬限制：
-
sizeof(From) != sizeof(To)：比如std::bit_cast<int64_t>(float{1.0f})</int64_t>，float是 4 字节，int64_t是 8 字节，编译器会报错（不是警告） - 任一类型非
trivially_copyable：比如std::string、含虚函数的类、有自定义析构函数的结构体，哪怕大小刚好匹配，也会被static_assert拦在编译期 - 目标类型带
const或volatile限定符：如std::bit_cast<const uint32_t>(f)</const>不合法；若真需要 const 值，应先 cast 再加 const 修饰
float ↔ uint32_t 是唯一真正“开箱即用”的安全组合
这不是经验之谈，而是由标准和硬件事实共同决定的：
- 两者都是 4 字节、
trivially_copyable、无 padding、对象表示完全一致（IEEE 754 单精度 + 32 位整数） - 可直接用于符号位提取：
uint32_t bits = std::bit_cast<uint32_t>(f); int sign = (bits >> 31) & 1;</uint32_t> - 反向构造也安全：
float f = std::bit_cast<float>(0x3f800000U);</float>得到 1.0f（但注意NaN位模式不标准化，平台间可能不同） - 别写
std::bit_cast<uint32_t>(&f)</uint32_t>—— 参数必须是值，不是指针；传地址会触发类型不匹配错误
和 memcpy / union / reinterpret_cast 对比时的关键差异
三者都能“看起来”完成相同操作，但语义和编译器认知完全不同：
立即学习“C++免费学习笔记（深入）”；
-
memcpy是通用内存拷贝，编译器可能无法优化掉中间存储，尤其在别名分析敏感场景下；而std::bit_cast明确告知“我只是重解释比特”，常被内联为单条mov指令 -
union在 C++17 后对标准布局类型读取非活跃成员有有限许可，但一旦结构体含 padding 或对齐差异，行为就不可靠；std::bit_cast完全绕过 union 生命周期规则 -
reinterpret_cast<uint32_t>(f)</uint32_t>是未定义行为（违反 strict aliasing），即使 -O0 跑得通，-O2 可能彻底优化错；std::bit_cast是标准认可的替代方案 - 性能上三者无实质差别，但
std::bit_cast唯一提供编译期保障 + constexpr 友好性：只要输入是常量表达式，结果就能用作模板参数
容易被忽略的对齐与跨平台陷阱
即便满足大小和 triviality，仍可能出问题：
- 源对象本身若未按目标类型对齐（例如栈上
char数组强制bit_cast到uint32_t），ARM64 等平台可能触发SIGBUS；std::bit_cast不做对齐检查，它信任你传入的对象地址合法 - 浮点格式非强制 IEEE 754：虽然主流平台都遵循，但标准不保证；用
std::bit_cast提取指数/尾数前，应确认平台一致性 - 不要试图用它绕过类型系统做“泛型序列化”：比如把任意
struct转成std::array<uint8_t n></uint8_t>，除非你能 100% 控制其填充、对齐、成员顺序，并验证std::is_trivially_copyable_v
