不违反严格别名规则时reinterpret_cast的合法使用场景有哪些？

首先要纠正一个核心误解：并非所有reinterpret_cast得到的异类型指针解引用都违反严格别名规则，严格别名本身有明确的合法例外，而且很多reinterpret_cast的使用场景根本不需要解引用转换后的指针，完全不会触发未定义行为。

以下是不违反规则的通用合法使用场景：

• 指针与足够宽度的整型类型互转
  这是最基础的用法：当你需要把内存地址打日志、做地址对齐计算、计算指针哈希值、或是把地址作为整型参数传给只接受整型的底层接口时，就可以用reinterpret_cast把指针转成std::uintptr_t/std::intptr_t类型。反过来如果拿到一个存储了有效地址的整型值，也可以用它转回原类型的指针。只要你不对转出来的整型做非法运算、最后转回的指针类型和原始类型完全一致，后续解引用就是完全合法的。
  比如写内存池时计算内存块头部偏移，就会把块指针转成uintptr_t加上偏移量，再转回char*做内存操作，全程没有UB。
• 对接不透明句柄、无类型用户数据接口
  你提到的厂商API场景是完全合法的，这里的核心逻辑是：提供不透明存储的API根本不会解引用你传进去的指针。不管是操作系统API还是第三方厂商的C接口，只要是提供“存储用户自定义数据”能力的接口，只会把你传入的指针值当成一个无意义的整数值存储，既不会读也不会写这个指针指向的内存，自然不存在异类型解引用违反别名规则的问题。等你需要取回数据时，把存进去的值用reinterpret_cast转回原来的类型指针再使用即可，全程符合标准要求。
  你担心的“厂商内部会解引用”是多余的：如果厂商需要解引用这个指针，就一定会明确要求指针指向的具体类型，那就不属于不透明数据接口的范畴了。
• 访问任意对象的底层字节表示
  严格别名规则有明确的豁免条款：允许用char、unsigned char、std::byte类型的指针访问任意类型对象的内存。也就是说你完全可以合法地把任意对象的指针用reinterpret_cast转成const std::byte*，逐字节读取对象内容做序列化、哈希计算、内存比对这类操作，这种解引用是标准明确允许的，不属于UB。
  反过来你也可以把字节缓冲区的指针转成普通类型指针——只要缓冲区满足对应类型的对齐要求，并且你已经通过placement new在对应位置构造了目标类型的对象，后续访问也是合法的，这是序列化、内存池实现的常规操作。
• 固定地址的底层硬件、内存映射访问
  做嵌入式、内核驱动开发时，经常需要访问固定物理地址映射的外设寄存器、进程间共享内存段，这类场景下目标内存位置本来就不存在预先定义的C++对象，你可以直接把代表地址的整型值用reinterpret_cast转成对应寄存器结构体、共享内存结构的指针直接读写，这也是标准允许的合法用法。
• 指针类型的往返转换
  你觉得“转成其他类型再转回来没有意义”是误解，这个用法是实现接口隔离的核心手段：比如你要写一个对外暴露C风格接口的C库，不可能在公共头文件里暴露内部的C类实现，否则就会把所有内部实现细节泄露给调用方。这种场景下的常规做法是对外只暴露一个不完全类型的不透明句柄（比如前置声明struct MyLibContext;，对外仅传递MyLibContext*类型的指针），内部实现时再把这个句柄指针用reinterpret_cast转回实际的C++类指针使用。这种场景下必须用reinterpret_cast做转换，根本不存在“直接用原始类型”的可能。

再回到你最开始写的int转float的代码：它之所以是未定义行为，问题根本不在reinterpret_cast本身，而在于你拿到float*之后，直接解引用了一个实际存储int对象的内存位置——int和float不属于允许别名的类型范畴，才触发了UB。这类位级别的类型转换，C20可以直接用std::bit_cast，C20之前用std::memcpy按字节拷贝也完全合法，不需要靠reinterpret_cast直接解引用异类型指针。

最后提几个常见的避坑点：

• 不要用reinterpret_cast做基类和派生类之间的指针转换，多重继承场景下这类转换不会自动做地址偏移，必然出问题，这类转换用static_cast即可，多态类型的向下转型用dynamic_cast。
• 指针转整型时不要用int、long这类宽度不匹配的类型，必须用std::uintptr_t/std::intptr_t，否则在64位平台上会出现指针截断导致崩溃。
• 永远不要用reinterpret_cast转两个无关的具体对象类型指针直接解引用做类型双关，这是最常见的触发严格别名UB的写法。

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