span不能作类字段或返回值，因其是ref struct，生命周期绑定栈帧，逃逸会导致未定义行为；跨方法、异步、长期持有应改用memory。
SpanMemory<t></t>。
为什么 Span 不能当类字段或返回给调用方？
Span<t></t> 是 ref struct，编译器强制它“不逃逸栈帧”——这意味着它不能被装箱、不能作为 class 的字段、不能出现在 async 方法的 await 点之后，也不能作为 public 方法的返回值（除非调用方也在同一栈帧内立即消费）。
常见错误现象：
- 写
public Span<byte> Buffer;</byte>→ 编译报错：CS8345: Field or auto-implemented property cannot be of type 'Span<t>' unless it is declared as 'static' or 'const'</t> - 在
async Task<span>> GetData()</span>中返回 → 编译失败，因为Span无法跨越 await 边界 - 存入
List<span>></span>→ 编译拒绝，Span不实现IEnumerable且不可装箱
根本原因：它的内部持有 ByReference<t></t>（本质是 ref），而 ref 语义要求生命周期严格绑定到声明它的栈帧。一旦逃逸，就可能访问已销毁的栈内存，引发未定义行为。
替代方案：
- 需要跨方法传递 → 改用
Memory<t></t>（可隐式转换自Span<t></t>） - 需要异步处理 → 先转成
Memory<t></t>，再用Memory<t>.Span</t>在同步段内操作 - 需要长期持有 → 考虑
ArrayPool<t>.Shared.Rent()</t>+ 普通数组，或直接用ReadOnlyMemory<t></t>
从字符串切片开始，别再用 Substring() 了
对临时解析（如 HTTP header 解析、JSON token 提取），string.AsSpan() 是 Substring() 的零分配替代品。它不创建新字符串对象，只返回一个指向原字符串底层字符数组的只读视图。
使用场景：
- HTTP 请求行解析：
ReadOnlySpan<char> method = line.AsSpan().Slice(0, line.IndexOf(' '))</char> - CSV 字段提取：先找逗号位置，再用
Slice(start, length)截取，全程无 string 分配 - 避免
ToString()引发的隐式分配（比如span.ToString()会触发堆分配）
注意点：
-
AsSpan()返回的是ReadOnlySpan<char></char>，不能修改原字符串（字符串本身是不可变的） - 若需修改内容（比如解码后覆盖），得先复制到可写的
Span<char></char>或Span<byte></byte>，例如用Encoding.UTF8.GetChars()写入 stackalloc 缓冲区 - 不要对
ReadOnlySpan<char></char>调用ToArray()—— 那就又回到分配老路了
stackalloc + Span：栈上分配的正确姿势
stackalloc 是唯一能直接在栈上分配原始内存的方式，配合 Span<t></t> 使用，可彻底规避 GC 压力。但它极易踩坑。
关键限制：
- 只能在
unsafe上下文中使用（项目需启用<allowunsafeblocks>true</allowunsafeblocks>） - 分配大小必须是编译期常量（
stackalloc byte[1024]✅，stackalloc byte[size]❌） - 单次分配建议 ≤ 8 KiB；超过易触发
StackOverflowException（且无法 catch）
典型安全用法：
private static unsafe int SumFirst1024(int[] data)
{
Span<int> stackSpan = stackalloc int[1024];
int len = Math.Min(data.Length, 1024);
data.AsSpan().Slice(0, len).CopyTo(stackSpan);
return stackSpan.Slice(0, len).Sum();
}</int>
不推荐：
-
Span<double> huge = stackalloc double[100000];</double>→ 极大概率崩溃 - 在递归函数中反复
stackalloc→ 栈空间线性增长，风险叠加 - 把
stackalloc得到的Span存入字段或返回 → 编译器会拦住，但思路本身危险
数组、指针、字符串，统一用 Span 处理的边界在哪？
Span<t></t> 的统一接口很诱人，但不同来源的内存有不可忽视的差异：
- 从
T[]创建（array.AsSpan()）→ 安全、高效、最常用 - 从
string创建（str.AsSpan()）→ 只读，且仅限char；不能用于 UTF-8 字节流解析（需先Encoding.UTF8.GetBytes()到byte[]） - 从指针创建（
new Span<byte>(ptr, length)</byte>）→ 必须unsafe，且需确保ptr有效、未释放、未越界；适合 P/Invoke 后的 native buffer 处理 - 从
stackalloc创建 → 生命周期严格受限，不能跨方法，不能异步
性能影响提示：
- 所有
Slice()都是 O(1)，但后续遍历是否高效，取决于底层内存是否连续、是否缓存友好（栈内存 > 托管堆 > native heap） - 对大数组做多次小
Slice()（如逐字节解析）比一次大Slice()+ 索引计算更慢——因每次Slice()都要检查长度，而循环内索引加法更轻量 -
Span<t>.Fill()</t>和.Clear()是高度优化的本机调用，比手动 for 循环快得多
真正容易被忽略的点：Span 的“零拷贝”优势，只在你**不把它转成数组、不调用 ToString、不跨作用域传递**时才成立。一旦破戒，前面省下的内存和时间，全在那一行代码里还回去。
