根本区别在于：Span是栈上安全、不可逃逸的切片类型，不能作字段或跨await；Memory是其可传递兄弟，支持异步但引入隐式生命周期管理开销。
MemoryArrayPool 或底层 Span 源可能触发分配——用错场景反而加重 GC 压力。
Memory 和 Span 的根本区别在哪
Span 是栈上安全的、不可逃逸的切片类型，不能作为字段、不能跨 await、不能装箱；Memory 是它的“可传递兄弟”，支持异步上下文，但引入了隐式生命周期管理开销。
-
Span只能在同步方法栈帧内使用（比如ref struct方法体内），传入参数必须是栈内存、数组或stackalloc分配的缓冲区 -
Memory可以作为方法返回值、类字段、async方法参数，但每次构造都可能触发ArrayPool或堆数组分配.Shared.Rent() - 误把
Memory当作“轻量引用”长期持有，尤其在高并发 handler 中缓存它，容易掩盖ArrayPool租借未归还的问题
ArrayPool 租借后不 Return 就等于内存泄漏
常见错误：在 using 块里用了 Memory，却没意识到它背后的数组没被归还——Memory 本身没有 IDisposable，Return 必须显式调用。
- 错误写法：
var mem = ArrayPool.Shared.Rent(1024); Process(mem); // 忘记 Return - 正确写法：
var array = ArrayPool.Shared.Rent(1024); try { Process(array); } finally { ArrayPool .Shared.Return(array); } - 更安全写法：封装成
using var rented = new PooledArray（自定义(1024); IDisposable包装器） - 监控手段：启用
DOTNET_SYSTEM_GC_TRACKED_OBJECTS=1+ dotnet-counters 观察System.Runtime/ArrayPool.RentedArrays计数是否持续上涨
MemoryMarshal.AsMemory 为什么有时会偷偷分配
MemoryMarshal.AsMemory 看似只是“包装”，但它只接受 Span 输入；若你传的是非托管指针（如 byte*）、或从 fixed 语句获取的地址，它内部会创建一个 MemoryManager 子类实例——这个对象本身分配在托管堆上。
- 典型陷阱：
fixed (byte* ptr = &buffer[0]) { var mem = MemoryMarshal.AsMemory(new Span—— 这里(ptr, len)); } mem生命周期超出fixed块时，CLR 会生成临时MemoryManager托管对象来维持 pinning - 替代方案：优先用
ArrayPool+.Shared.Rent() Memory，避免混合托管/非托管边界操作 - 调试技巧：在 Release 模式下用
dotnet-dump analyze查看堆中是否存在大量System.Buffers.MemoryManager`1+OverlappedMemoryManager实例
GCSettings.LatencyMode 影响 Memory 的实际行为
设为 GCLatencyMode.LowLatency 后，GC 不再回收 LOH（大对象堆），而 ArrayPool 在租借大尺寸数组（>85KB）时默认分配到 LOH —— 此时池化失效，每次 Rent 都变成新分配。
- 现象：
ArrayPool在 LowLatency 模式下反复调用，.Shared.Rent(100_000) Gen2 GC计数几乎为 0，但私有字节数持续上涨 - 对策：对大尺寸场景，改用
ArrayPool显式控制块大小，避免落入 LOH.Create(minBlockSize: 100_000, maxArrayLength: 100_000) - 注意：
GCSettings.LatencyMode是进程级设置，切勿在库代码中擅自修改，应在宿主应用启动时统一配置
真正难的不是写出 Memory，而是判断它背后的内存所有权是否清晰、生命周期是否可控。一旦涉及跨线程、跨 await、跨 native 边界，就该立刻检查 MemoryManager 是否被隐式创建、ArrayPool 是否漏 Return、LOH 是否意外膨胀——这些地方不会报错，但会在压测时突然暴露。
