Unsafe指针操作替换为MemoryMarshal.Write的结果一致性及潜在边界问题问询

没错，在你假设输入完全合法的前提下，这两种方法的执行结果是100%一致的。我来帮你拆解细节，打消你的顾虑：

核心逻辑的等效性 #

• 不管是用unsafe指针直接赋值，还是用MemoryMarshal.Write，底层做的都是同一件事：把目标值的二进制内存表示，按当前进程的原生字节序直接复制到字节数组的指定偏移位置。
• 对于你测试的short、int、long这类基本数值类型，以及简单的blittable结构体（内存布局固定、无需CLR额外处理的结构体），两者的内存操作逻辑完全对齐，没有任何转换或封装差异。

关于你发现的JIT反汇编差异 #

你提到的越界访问行为差异，本质是运行时安全检查的区别，而非写入逻辑本身：

• unsafe指针版本默认跳过了数组边界检查（除非你手动添加），所以非法输入可能会直接导致内存访问错误；
• MemoryMarshal.Write依托Span的机制，在Debug模式下会主动做边界检查（Release模式下JIT会对合法输入的检查进行优化），非法输入会抛出ArgumentOutOfRangeException。
  但既然你已经明确输入合法，这种检查差异不会影响最终的写入结果。

有没有未预料的边界情况？ #

只要你处理的是blittable类型，就不会有意外：

• 非blittable类型（比如包含引用类型的结构体、需要自定义序列化逻辑的类型）本身就不适合用这两种方法来写入，所以不在你的场景范围内；
• 字节序方面，两者都严格遵循当前系统的原生字节序（比如x86/x64是小端，部分ARM架构是大端），不会出现不一致的情况。

性能与扩展优势 #

你提到的.NET Core 3.1基准测试结果很靠谱：

• Span-based的方法性能更优，一方面是因为Span的底层实现经过深度优化，另一方面MemoryMarshal是专门为托管内存操作设计的API，避免了fixed语句带来的额外固定开销；
• 后续如果把方法签名改成用Span，还可以借助stackalloc在栈上分配临时数组，彻底避免堆分配和GC压力，这在高频调用的场景下优势会非常显著。

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