对于这种类型的二进制IO操作，持久性会是一个问题吗

是的，如果从BE保存的文件加载到LE上，或者反之亦然，这将导致问题。这就是为什么一些Unicode编码（如UTF-16和UTF-32）具有所谓的字节顺序标记的原因。

如果你的代码通常是在BE上编译的，那么在使用数据之前，你仍然必须确保LE代码会交换字节顺序。

CPU设置Endianess，并且一些芯片（例如，一些MIPS CPU）允许在引导系统时切换Endianess。

我们可以使用更多的信息。跨平台是一回事，但什么平台呢？如果你指的是像x86 Mac、x86 Linux和x86 Windows这样的跨平台，那么不，你不需要担心它（尽管如果你试图将结构转发到磁盘并在不同平台上使用不同的编译器进行编译，结构打包可能仍然是一个问题）。即使你有几个不同的OS/CPU组合，你也可以列出你想要支持的一切，如果它们都有相同的endianes，也不用担心。

如果你不期望保存数据会从一个平台移动到另一个平台，你也不必担心。只有当你想在大端机器上创建数据，然后在小端机器上读取数据时，端性才是一个问题，反之亦然。如果这些只是本地数据文件，那没什么大不了的，尽管可以放心地假设，如果你的用户可以将他们的保存从一个平台复制到另一个平台，他们会的，因为他们几乎会做任何你不想让他们做也不支持的事情。

此外，由于您只提到了字节，如果字节数组和数据一样复杂，那么实际上不需要担心字节序。这只是多字节数据类型的问题。因此，如果您只是保存字节数组，而其他记账数据也适用于字节，则无需担心，但一旦保存short、int或float，就会出现潜在的endian问题。

我个人的观点是，无论何时序列化，都要考虑到endianes，但我有一个非常多平台的背景（即在5个游戏系统上运送相同的产品）。这很容易，交换宏已经存在，当你不可避免地决定转移到另一个endianes时，你不必重写东西。如果数据更复杂或更结构化，可以考虑像Protocol Buffers或BSON这样的库。

CPU和操作系统都可能负责端序。从历史上看，它是被烘焙到CPU中的，尽管x86仍然是硬连接的小端，但大多数现代RISC衍生物可以在任何一种模式下运行，这使它成为硬件和操作系统开发人员的选择。