Unsafe.SkipInit 不能替代 new T()，因其不调用构造函数且不保证字段为默认值，对含引用字段的类型易致 NullReferenceException 或野指针，仅适用于无引用、无构造依赖的纯数据 struct。
Unsafe.SkipInit 为什么不能替代 new T()？
它不调用构造函数，也不保证字段初始化为默认值——这意味着 T 类型的实例可能包含任意内存残留数据。对引用类型（如 string、List<int>）使用 Unsafe.SkipInit<T>() 后直接访问字段，大概率触发 NullReferenceException 或读取到野指针；对值类型（如 struct）虽可绕过零初始化开销，但若结构体含引用字段或依赖构造逻辑（例如内部缓存、状态标记），行为完全不可控。
- 仅适用于无引用字段、无构造依赖、且明确需要跳过零初始化的纯数据
struct - 编译器不会检查是否安全，运行时也不会报错，错误表现为随机崩溃或静默数据污染
-
Unsafe.SkipInit<int>()和default(int)表现相同，但前者不生成零写入指令；而Unsafe.SkipInit<MyStruct>()若MyStruct含string name;字段，则name是未定义的垃圾地址
哪些场景下值得冒险用 SkipInit？
典型适用场景非常窄：高频分配大量同构、无引用字段的 struct，且后续会立即覆写全部字段（例如解析二进制流、GPU 数据映射、ring buffer 批量填充）。此时跳过默认初始化能减少内存带宽压力，尤其在 Span<T> 或 ArrayPool<T> 回收再利用时收益明显。
- 配合
Span<T>.Fill(default)的反模式：先SkipInit再Fill不如直接用stackalloc T[n]或池化数组 +AsSpan().Clear() - 真正有效的是“分配 → 按字节/字段批量写入 → 使用”，例如用
BinaryPrimitives直接向Span<byte>写入结构体字段 - 必须搭配
Unsafe.AsRef<T>或MemoryMarshal.Cast使用，不能直接赋值给托管变量再操作
如何检测 SkipInit 是否被误用？
没有编译期检查，只能靠运行时验证和工具链辅助。最有效的办法是开启 ConcurrentGC + GCStress=3（.NET SDK 自带），它会让 GC 在非预期时机触发并填充内存为特定毒值（如 0xFEEEFEEE），此时若 SkipInit 返回的 struct 引用字段未被及时赋值，立刻崩在毒值解引用上。
- 静态分析可用
Microsoft.CodeAnalysis.NetAnalyzers的CA2015（但默认不覆盖SkipInit调用） - 单元测试中对使用
SkipInit的代码路径，强制用GC.Collect(2, GCCollectionMode.Forced, true)后再访问，观察是否出现异常 - 关键路径建议加断言：
Debug.Assert(!Unsafe.AsRef<T>(ptr).SomeReferenceField is null, "SkipInit struct field not initialized");
替代方案比 SkipInit 更可靠
99% 的所谓“性能瓶颈”其实来自内存分配本身，而非初始化开销。优先考虑：ArrayPool<T> 复用缓冲区、Span<T> 栈分配、或把结构体拆成多个同质数组（SOA）避免无效字段初始化。只有在 perfview 明确定位到 initblk 或 stobj 指令成为热点，且其他优化已穷尽时，才应评估 SkipInit。
它不是高性能银弹，而是把内存安全责任完全移交给你——连 unsafe 关键字都比它更“有提示”。用错一次，调试成本远超省下的几个纳秒。
