Span.Split() 不能直接用，得手写切分逻辑
Span<char></char>没有内置的
Split()方法——这是很多人第一次尝试时卡住的地方。.NET 的
Span<t></t>是只读/可写的连续内存视图，设计上不带高阶字符串操作，所有切分必须手动遍历 + 记录边界。
常见错误是试图调用
span.Split(' ')，结果编译失败，报错：CS1061 'Span<char>' does not contain a definition for 'Split'</char>。 替代方案是用
IndexOf()或
IndexOfAny()找分隔符位置，再用切片（
span[start..end]）提取子段 若分隔符固定且单一（如空格、逗号），
IndexOf()性能最好；含多个可能分隔符（如空白符 \t\n\r ），优先用
IndexOfAny(new char[] {' ', '\t', '\n', '\r'})
注意：切片操作本身不分配内存，但若需长期持有某段内容，得显式转成 string或
ReadOnlyMemory<char></char>，否则 span 生命周期受限于原始数据
用 ReadOnlySpan 解析 CSV 行的典型模式
处理日志、TSV、简单 CSV 时，避免分配 string 数组是关键。下面是一个跳过引号、不支持嵌套逗号的轻量解析示例：
static ReadOnlySpan<char>[] ParseCsvLine(ReadOnlySpan<char> line)
{
var parts = new List<ReadOnlySpan<char>>();
int start = 0;
int i = 0;
while (i < line.Length)
{
if (line[i] == ',')
{
parts.Add(line[start..i]);
start = i + 1;
}
i++;
}
parts.Add(line[start..]); // 最后一段
return parts.ToArray();
}
这个函数全程零堆分配，但要注意：
没处理转义和引号包裹字段（如"a,b",c），真实 CSV 应改用
Microsoft.VisualBasic.FileIO.TextFieldParser或第三方库 返回的是
ReadOnlySpan<char>[]</char>，数组本身在堆上，但每个元素指向原 span 的子区域，不复制字符 如果后续要传给需要
string的 API（比如
int.TryParse()的重载），得用
ToString()—— 这一步会触发分配，无法避免
IndexOfAny + 切片比 string.Split() 快多少？
在纯 ASCII 文本、分隔符明确的场景下，
ReadOnlySpan<char>.IndexOfAny()</char>+ 手动切片通常比
string.Split()快 2–5 倍，主要省在三处： 不创建中间
string[]数组（尤其当字段数多时，GC 压力明显下降） 不为每个字段新分配
string对象（
Span切片只是指针偏移） 可提前退出（比如只取前 3 个字段，后面全跳过），而
Split()总是全量解析
但性能优势有前提：原始数据已是
ReadOnlySpan<char></char>或能低成本获得（如从
stackalloc char[256]或
MemoryPool<char>.Rent()</char>获取）。如果源头是
string，又只解析一两次，用
string.AsSpan()转换开销极小，仍值得；但如果反复从 heap string 构造 span 再切分，收益会被抵消。
别忘了 Span 生命周期和栈空间限制
最容易被忽略的是：你不能把
Span<char></char>存到类字段或返回给不确定生命周期的调用方。例如下面代码是非法的：
private Span<char> _buffer; // ❌ 编译错误：Span cannot be used as a field type Span<char> GetSpan() => stackalloc char[64]; // ❌ 返回 stackalloc span 给调用方是危险的
这意味着：
所有Span处理必须在单个同步方法内完成，或通过
ReadOnlySpan<char></char>作为参数向下传递 想跨方法复用缓冲区？改用
Memory<char></char>+
MemoryPool<char>.Rent()</char>，它管理堆内存但依然避免重复分配 处理超长行（比如 > 1MB）时，
stackalloc会触发栈溢出，此时必须切到堆内存或流式分块处理
Span 的高效，始终绑定在“短生命周期 + 明确作用域”上。一旦脱离这个前提，它就不是银弹，而是隐患。
