Memory 和 Span 本身不支持跨线程共享
Span<t></t>是栈分配的，不能逃逸到堆上，因此无法作为字段、参数（除非
ref）、返回值或异步状态机中的成员；
Memory<t></t>虽可跨方法传递，但其内部实现（如
ArrayMemoryManager或
NativeMemoryManager）**不保证线程安全**。直接在多个
Task间读写同一块
Memory<t></t>或
Span<t></t>所指向的底层数据（比如同一个
byte[]），会引发竞态——尤其当其中任一任务执行写操作时。
正确共享底层数据：用 ArrayPool.Shared + 同步策略
若需多任务协作处理同一片内存（如解析网络包、批量压缩），应把「共享」落在可安全并发访问的底层容器上，而非
Memory<t></t>本身。最常用且高效的方式是结合
ArrayPool<byte></byte>与显式同步：
ArrayPool<byte>.Shared.Rent(int)</byte>获取数组，再封装为
Memory<byte></byte>供各任务使用 读操作通常无需锁（前提是无写入者），但只要存在写任务，就必须对共享区域加锁（如
lock(array)或
SpinLock） 避免将
Span<t></t>传入
async方法——它会在 await 后失效；改用
Memory<t></t>并确保其生命周期被正确管理 任务结束后必须调用
ArrayPool<byte>.Shared.Return(array)</byte>，否则池泄漏
var pool = ArrayPool<byte>.Shared;
var buffer = pool.Rent(8192);
try
{
var mem = new Memory<byte>(buffer);
// 分发给多个 Task 处理不同 slice，例如：
var task1 = ProcessSliceAsync(mem.Slice(0, 4096));
var task2 = ProcessSliceAsync(mem.Slice(4096, 4096));
await Task.WhenAll(task1, task2);
}
finally
{
pool.Return(buffer); // 必须放回
}
需要真正“共享视图”？考虑 ReadOnlySequence + PipeReader
如果场景是流式数据（如 HTTP body、日志行解析），且多个消费者需按需读取同一份字节流，
ReadOnlySequence<byte></byte>是更合适的选择——它天然支持零拷贝切片、跨线程传递，并与
PipeReader配合实现生产者-消费者解耦：
PipeReader的
ReadAsync()返回
ReadResult，其中
Buffer是
ReadOnlySequence<byte></byte>该序列可安全地传递给多个
Task，每个任务调用
slice.CopyTo(...)或
slice.ToArray()做局部拷贝处理 底层由
Pipe管理内存生命周期，无需手动归还 注意：直接在多个任务中并发调用
sequence.First.Span仍可能因底层
MemoryManager实现而有风险，推荐用
sequence.CopyTo(Span<byte>)</byte>或转成数组后再处理
绝对禁止的操作和典型错误
以下写法看似简洁，实则危险：
把Span<byte></byte>存入
ConcurrentQueue<span>></span>—— 编译不过，
Span<t></t>不可赋值给泛型集合 在
async方法中捕获
Span<t></t>并 await —— 运行时报
System.InvalidOperationException: Cannot use a Span<t> across await</t>多个
Task直接写入同一
Memory<byte></byte>的不同 offset，却不加锁 —— 数据被覆盖，无任何编译或运行时提示 用
MemoryMarshal.AsMemory(byte[].AsSpan())包装一个被其他线程修改的数组，且未同步 —— 竞态照旧
关键点始终是：共享的是数据容器（
byte[]、
Pipe、
ArrayPool租赁块），不是
Span或
Memory本身；所有写操作都必须有明确的同步边界。
