MemoryStream写入后读不到数据是因为位置指针停留在末尾，需调用Seek(0, SeekOrigin.Begin)重置；ToArray()会复制内存，高频场景应改用GetBuffer()配合Length截取，或直接传递Stream实例。
MemoryStream 写入后读不到数据？记得 Seek(0, SeekOrigin.Begin)
刚写完字节到 memorystream 就调 read 或转 toarray()，结果读空或长度为 0——不是流坏了，是位置指针卡在末尾了。它不像文件流会自动重置，写完必须手动“倒带”。
- 写入后立刻读：调用
stream.Seek(0, SeekOrigin.Begin)，否则Read从当前位置（即末尾）开始，返回 0 字节 - 想直接拿全部内容：用
stream.ToArray()或stream.GetBuffer()（注意后者可能含未使用冗余空间） -
GetBuffer()返回的是底层数组引用，如果后续还会写，得配合stream.Length截取有效部分，别直接当完整数据用
用 MemoryStream 做 JSON 序列化缓冲？小心 ToArray() 的内存复制开销
常见做法是把 JsonSerializer.Serialize 写进 MemoryStream，再 ToArray() 拿 byte[]。但每次 ToArray() 都会分配新数组并拷贝——高频调用时 GC 压力明显。
- 低频、小数据：直接
ToArray()最简单，别过早优化 - 高频或大数据：改用
stream.GetBuffer()+(int)stream.Length截取，避免额外拷贝 - 如果下游接受
Stream（比如HttpResponse.Body），干脆别转数组，直接传MemoryStream实例，让它自己读
构造 MemoryStream 时传入 byte[]，为什么修改原数组会影响流？
因为 new MemoryStream(byte[] buffer) 是“共享底层数组”的构造方式，不是拷贝。改原数组，流里读出来的内容就变了；反过来，往流里写（且没设 writable=false）也会改原数组。
- 想只读且隔离：用
new MemoryStream(buffer, readOnly: true)，但数组仍被引用，只是禁止写 - 想彻底隔离：用
new MemoryStream(buffer.Clone() as byte[])或new MemoryStream(buffer.Length)+Write拷贝进去 - 注意
buffer.Length和stream.Length可能不等：构造后流长度 = 数组长度，但之后写操作会扩展（除非用只读模式）
异步方法里用 MemoryStream，CopyToAsync 和 WriteAsync 有啥区别？
都支持 async，但行为差异影响错误处理和资源释放时机。
-
CopyToAsync(destination)：把整个流内容异步写到目标流，自动处理缓冲区、分块、完成回调，适合“管道式”转发 -
WriteAsync(buffer, offset, count)：只写你给的那块内存，不关心源流是否读完，需自己控制循环和 EOF 判断 - 重要陷阱：
MemoryStream的异步方法实际是同步实现（没有 I/O 等待），但必须按 async 签名调用，否则可能触发InvalidOperationException（尤其在 ASP.NET Core 中被中间件检查）
实际用的时候，最常漏掉的是 Seek(0, SeekOrigin.Begin)，其次是误以为 GetBuffer() 返回的就是“干净”的数据切片。这两处一错，调试半天都在查数据哪去了。
