MemoryStream写入后Position在末尾，需手动设为0才能读取；ToArray()安全但有开销，GetBuffer()零分配但危险；传byte[]构造时writable=false则只读；它非线程安全。
MemoryStream 写入后 Position 为末尾，直接读会返回空
这是最常踩的坑：用 Write() 往 MemoryStream 写完数据后，Position 停在流末尾。此时若直接调用 Read() 或 ToArray()（后者没问题），但若想用 Read() 逐段读，会因位置不对而读不到任何字节。
正确做法是写完后手动重置位置：
var ms = new MemoryStream();
ms.Write(Encoding.UTF8.GetBytes("hello"));
ms.Position = 0; // ⚠️ 必须加这句才能从头读
- 别依赖构造函数传入字节数组来“自动可读”——那只是初始化内部缓冲区，
Position仍为 0，但写操作会改变它 -
ToArray()总是返回完整缓冲区副本，不受Position影响；而GetBuffer()返回底层引用，可能含未使用尾部垃圾字节，且不保证长度准确 - 如果只写一次、只读一次，优先用
ToArray()，安全省心
用 MemoryStream 包装已有 byte[] 时，是否可写取决于构造方式
传入字节数组构造 MemoryStream 时，行为分两种：
// 可读可写，且允许扩容（内部会复制数组） var ms1 = new MemoryStream(byteArray); // 只读（IsWritable == false），不可调用 Write()，否则抛 NotSupportedException var ms2 = new MemoryStream(byteArray, writable: false);
- 默认构造（无参）或仅传
capacity的，初始为空，可写，会动态扩容 - 传入
byte[]+writable: false是常见优化手段——避免意外修改原始数据，也防止误写导致越界 - 若需只读但又想支持
Seek()，必须确保CanSeek == true（默认满足），否则Position设值会失败
ToArray() 和 GetBuffer() 的性能与安全性差异
ToArray() 每次都拷贝一份新数组，安全但有分配开销；GetBuffer() 直接返回内部缓冲区引用，零分配但危险。
-
ToArray()返回的数组长度 = 实际写入长度（Length），干净可靠，适合导出、序列化、跨线程传递 -
GetBuffer()返回的数组长度 ≥Length，末尾可能有未初始化垃圾字节；且若后续对MemoryStream扩容，缓冲区可能被替换，原引用失效 - 除非你在高性能循环中反复读同一段内存、且能严格控制生命周期（比如解析网络包时临时复用缓冲区），否则一律用
ToArray() - 注意：
GetBuffer()在MemoryStream被Dispose()后仍可访问——但这属于未定义行为，不要依赖
和 Span/Memory 混用时的常见陷阱
.NET Core 2.1+ 支持 MemoryStream 构造时传 Memory<byte></byte>，但要注意：该构造函数创建的是只读流（IsWritable == false），且底层不持有引用，而是复制内容。
- 想把
Span<byte></byte>写入流？只能先转成byte[]或用MemoryStream.Write(Span<byte>)</byte>实例方法（要求流可写） -
MemoryStream.TryGetBuffer(out ArraySegment<byte>)</byte>已废弃，.NET 5+ 推荐用GetArray()（仅当底层是数组时才有效），但多数场景不如直接ToArray() - 跨线程共享
MemoryStream实例？不行。它不是线程安全的——Position、缓冲区扩容等操作都非原子，需外层加锁或改用Stream子类替代方案
GetBuffer() 返回的数组实际容量、Position 在异步写之后的状态、或者 MemoryStream 被 Dispose() 后对 ToArray() 的影响——这些地方容易绕进去半天。 
