ref struct 必须显式声明为 ref struct 且不能继承，仅限栈分配，不可装箱、不可作字段、不可实现接口；典型用于 Span 封装等零开销短期访问场景。
ref struct 必须显式声明且不能继承
在 C# 中，ref struct 是一种编译器强制限制只能在栈上分配的类型，它不能被装箱、不能作为字段存在于普通 class 或 struct 中、也不能实现任何接口（包括 IDisposable）。声明时必须用 ref struct 关键字，不能写成 struct 后加修饰——编译器会直接报错：error CS8342: A ref struct cannot be used as a type argument 或类似提示。
常见错误是试图把它当普通结构体用：
- 放在 class 字段里 → 编译失败
- 放进
List<t></t>或数组 → 编译失败（因为涉及堆分配或泛型约束） - 作为 async 方法的局部变量 → 编译失败（await 可能导致栈帧迁移）
ref struct 的典型使用场景：Span 和 ReadOnlySpan 的替代封装
最合理的用途是封装对栈内存或固定缓冲区的短期、零开销访问，比如高性能解析器、底层互操作包装、或避免 GC 压力的临时切片。例如：
ref struct Utf8CharReader
{
private ReadOnlySpan<byte> _data;
private int _pos;
<pre class="brush:php;toolbar:false;">public Utf8CharReader(ReadOnlySpan<byte> data) => (_data, _pos) = (data, 0);
public bool TryRead(out char c)
{
if (_pos >= _data.Length) { c = '\0'; return false; }
// 简化逻辑：只处理 ASCII
c = (char)_data[_pos++];
return true;
}}
这个类型只能在方法栈帧内存在，调用方必须保证生命周期不逃逸——比如不能返回它、不能存入 static 字段、不能传给需要 object 的 API。
ref struct 不能跨 await 或 yield，也不能捕获到 lambda 中
因为 ref struct 的地址绑定到当前栈帧，而 await 可能导致方法恢复在另一个线程/栈上执行，yield return 会生成状态机（堆分配），lambda 捕获则可能延长其生命周期至委托对象中。编译器对此有严格检查：
- 在 async 方法中声明
ref struct变量 →error CS8347: Cannot use a ref struct 'X' in an async method -
Task.Run(() => { var x = new MyRefStruct(); })→ 编译失败，lambda 无法捕获 ref struct -
foreach (var item in someCollection) { ref struct s = ...; }→ OK，只要 s 不逃出该循环体
ref struct 的构造与生命周期完全由作用域控制
没有自定义构造函数（只能有实例方法和初始化器），不能有 finalizer，也不支持 new 在堆上分配。它的“创建”就是栈变量声明本身：
Span<int> stackBuffer = stackalloc int[128]; Utf8CharReader reader = new Utf8CharReader(stackBuffer); // OK：stackalloc + ref struct 都在栈上
注意：stackalloc 返回的 Span<t></t> 本身就是 ref struct，所以所有基于它的封装都天然受相同约束。一旦你尝试把 ref struct 赋值给 object、放进 Dictionary<string object></string>、或者作为参数传给非 ref struct 兼容的泛型方法，编译器立刻拦截。
最容易被忽略的一点：即使没显式 new 或 return，只要变量被隐式提升（比如用在本地函数里，而该本地函数又被闭包捕获），也会触发错误。ref struct 的“栈性”不是运行时保证，而是编译期全链路跟踪——漏掉任意一环，就过不了编译。
