C# ref struct 栈上分配方法：高级使用指南
在追求极致性能与内存安全的场景下，C#的ref struct是一个强大但需要谨慎驾驭的工具。它强制类型实例完全存活于栈上，从而避免了堆分配的开销，但同时也带来了一系列严格的编译期约束。理解并遵循这些规则，是将其威力安全释放的关键。
ref struct 声明必须带 ref 关键字，不能省略或后置
这里有个硬性规定：编译器不接受struct MyRefStruct这种写法。即便你只在内部使用ref字段，也必须显式地加上ref关键字，写成ref struct MyRefStruct。否则，等待你的将是CS8342这类错误提示。
几个常见的“踩坑”操作包括：
- 试图给已有的普通
struct加上ref修饰符？行不通。这并非语法糖，而是一个全新的类型类别。 - 想让
ref struct继承点什么？不允许。它甚至连: IDisposable这样的接口都不能实现。 - 在泛型约束之外，把它用作类型参数，比如
List？编译会直接失败，因为泛型容器默认就拒绝ref struct。
ref struct 不能逃逸出当前栈帧，async/lambda/yield 是高危区
ref struct的生命周期被严格绑定在声明它的那个栈帧里。一旦它有可能跨越栈帧边界——例如在await暂停后恢复、通过yield返回状态机、或者被lambda捕获后存入委托——编译器会立刻出手拦截。
来看看几个典型的错误场景：
async Task Foo() { var x = new MyRefStruct(); await Task.Delay(1); }→ 触发CS8350错误。Task.Run(() => { var x = new MyRefStruct(); })→lambda捕获导致变量逃逸，编译失败。foreach (var item in list) { ref struct s = ...; DoSomething(s); }→ 只要s不离开这个循环体，就是合法的。
判断的核心点在于：观察这个变量是否有可能被“带走”。无论是作为返回值、存入字段，还是传递给异步方法、委托或迭代器，这些都是被明令禁止的动作。
ref 字段只能出现在 ref struct 内部，且必须手动绑定有效地址
这里的ref字段并非自动初始化的引用。本质上，它是一个用于存储栈地址的槽位，必须在构造逻辑中，通过ref表达式进行显式赋值。
正确的写法示例如下：
public ref struct RefFieldExample
{
private ref int _value;
public RefFieldExample(ref int source)
{
_value = ref source;
}
public int GetValue() => _value;
}
有几个细节需要特别注意：
- 声明时是
private ref int _value;，注意ref和int之间有空格，而private ref int（中间无空格）是非法语法。 - 未初始化的
ref字段进行读取会引发NullReferenceException。建议使用Unsafe.IsNullRef(ref _value)来检查其有效性。 - 它不能指向方法返回的临时值等局部变量以外的内存，否则编译器会报出“ref safety violation”错误。
C# 13 起支持 where T : ref struct，但泛型容器仍受限
从C# 13开始，ref struct可以作为泛型类型参数了，但前提是必须加上显式的约束：
public class Poolwhere T : ref struct { private T[] _buffer; // ❌ 仍然不行：数组本身是引用类型，其元素不能是 ref struct private Span _span; // ✅ 合法：Span 天然支持 ref struct 元素 }
那么，现在能做什么呢？
- 可以作为方法参数传入（按值传递，实际复制的是栈地址）。
- 可以被
ref返回（例如public ref Span）。GetData() => ref _data; - 可以用于
Span、ReadOnlySpan等原生就支持栈安全的类型。
但依然不能做的包括：
- 放进
T[]、List、Task——这些结构都隐含着堆分配或装箱的风险。 - 作为
object或接口类型来接收，哪怕只是临时转换一下，编译器也会直接拦住。
说到底，真正的难点往往不在于“怎么写”，而在于“如何确保整条调用链都不让它逃逸”。即使是一个看似无害的ToString()调用，如果其背后隐式使用了object参数，也可能导致问题。栈安全是一份贯穿全程的契约，而非一个可以随意开关的单点选项。
