1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

public abstract class Stream : MarshalByRefObject, IAsyncDisposable, IDisposable
{
    public abstract bool CanRead { get; }
    public abstract bool CanWrite { get; }
    public abstract bool CanSeek { get; }
    public abstract long Length { get; }
    public abstract long Position { get; set; }

    public abstract int Read(byte[] buffer, int offset, int count);
    public abstract void Write(byte[] buffer, int offset, int count);
    public abstract long Seek(long offset, SeekOrigin origin);
    public abstract void SetLength(long value);
    public abstract void Flush();
}

1
2
3
4
5
6
7
8
9

设计意图：
  让"读文件 / 读网络 / 读内存 / 读加密"用同一套 API
  → 业务代码只依赖 Stream，不依赖具体实现
  → 可以层层包装（装饰器模式）

代价：
  → 抽象被迫提供所有方法，但每个子类都不一定能实现
  → CanRead / CanWrite / CanSeek 标志位遍布 API
  → 不支持的操作直接抛 NotSupportedException

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

能力            属性            典型实现
─────────────────────────────────────────────────
Read            CanRead         FileStream / NetworkStream / MemoryStream
Write           CanWrite        FileStream / NetworkStream / MemoryStream
Seek            CanSeek         FileStream ✅ / NetworkStream ❌ / MemoryStream ✅
Timeout         CanTimeout      NetworkStream ✅ / FileStream ❌

CanSeek = false 时：
  - Position / Length / SetLength / Seek 都抛 NotSupportedException
  - Position 是"游标"概念，对网络流没意义

CanTimeout = true 时：
  - ReadTimeout / WriteTimeout 控制读写超时（毫秒）
  - 实际效果因实现而异（FileStream 在 Windows 上有 native 重叠 IO）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

public class NullStream : Stream   // 实际叫 Stream.Null
{
    public override bool CanRead => true;
    public override bool CanWrite => true;
    public override bool CanSeek => true;
    public override long Length => 0;
    public override long Position { get; set; }

    public override int Read(byte[] buf, int off, int count) => 0;  // EOF
    public override void Write(byte[] buf, int off, int count) { /* 丢弃 */ }
    public override long Seek(long off, SeekOrigin org) => off;
    public override void Flush() { }
    public override void SetLength(long v) { }
}

1
2
3
4
5
6
7

// ❌ 高风险写法
public async Task<byte[]> ReadNAsync(Stream s, int n)
{
    byte[] buf = new byte[n];
    int read = await s.ReadAsync(buf, 0, n);   // ⚠️ read 可能 < n
    return buf;   // ⚠️ 后半段可能是 0
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

为什么 Read 可能返回少于请求？
  - FileStream：通常能读满（除非到 EOF）
  - NetworkStream：可能 1 字节就返回！
    * TCP 是字节流，每次 Read 看到的是"当前缓冲区到达的数据"
    * 没有"凑够 N 字节"的概念
    * 如果对方写 4 字节后 sleep，下次 Read 就只有 4 字节

  - CryptoStream：可能解一帧就返回
  - GZipStream：可能解一 chunk 就返回

→ 契约：Read 返回"实际读到的字节数"，可能是 0（EOF）到 count

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

public static async Task<int> ReadExactAsync(Stream s, byte[] buf, int offset, int count)
{
    int total = 0;
    while (total < count)
    {
        int read = await s.ReadAsync(buf, offset + total, count - total);
        if (read == 0) break;  // EOF
        total += read;
    }
    return total;
}

// .NET 6+ 已经原生提供：
await s.ReadExactlyAsync(buf);          // 读满，否则抛 EndOfStreamException
await s.ReadAtLeastAsync(buf, 100);     // 至少 100 字节

1
2
3
4
5
6
7

ReadExactly 的实现：
  .NET 6 引入的"长痛不如短痛"API
  替代手写循环（手写循环是 .NET 头号反模式之一）

注意：ReadExactly 在网络流上"卡住"直到读满或 EOF
  → 必须配合 CancellationToken
  → 否则恶意对端可以让调用永久阻塞

1
2
3
4
5
6
7
8

0 = EOF（流结束）
1~count = 实际读到
异常 = IO 错误

注意：
  - NetworkStream 上对端关连接 → Read 返回 0
  - 永远不会"Read 返回 0 然后又读到数据"
  - 收到 0 后再调 Read 还是 0

1
2
3

byte[] buf = new byte[1024];
int read = stream.Read(buf, 0, 1024);
stream.Write(buf, 0, read);

1
2
3
4

问题：
  - 同步阻塞 → 高并发下线程爆炸
  - byte[] 必须分配 → GC 压力
  - offset + count 三参数 → 容易越界

1
2

stream.BeginRead(buf, 0, 1024, callback, state);
// 在 callback 里调 EndRead 拿到字节数

1
2
3
4

问题：
  - 回调地狱
  - 状态对象装箱
  - 异常处理复杂

1

int read = await stream.ReadAsync(buf, 0, 1024);

1
2
3

问题：
  - 仍然 byte[] 分配
  - Task<int> 装箱（每个 await 一个 Task 对象）

1
2
3
4
5
6
7
8
9

// 同步版本
int read = stream.Read(buf.AsSpan(0, 1024));

// 异步版本（基于 ValueTask）
int read = await stream.ReadAsync(buf.AsMemory(0, 1024));

// stackalloc 友好
Span<byte> stackBuf = stackalloc byte[256];
stream.Read(stackBuf);

1
2
3
4
5
6
7
8

改进：
  - Span 零分配
  - ValueTask<int> 避免每次 await 创建 Task
  - 可以用 stackalloc

遗留：
  - 仍然要"主动拉"（pull）
  - 仍然要循环到 N 字节

1
2

await stream.ReadExactlyAsync(buf);  // 自动循环
await stream.ReadAtLeastAsync(buf, 100, throwOnEndOfStream: false);

1
2
3
4
5
6
7
8
9

PipeReader reader = PipeReader.Create(stream);
ReadResult result = await reader.ReadAsync();
ReadOnlySequence<byte> buffer = result.Buffer;

// 处理 buffer（多段 Memory 拼接）
ProcessProtocol(buffer);

// 告诉 reader "我处理了多少"
reader.AdvanceTo(buffer.Start, buffer.End);

1
2
3
4
5
6
7
8

革命性：
  1. 不用自己分配 buffer（Pipe 内部池化）
  2. 不用循环到 N 字节（Pipe 自动缓冲）
  3. 多段连续内存（ReadOnlySequence<byte>）
  4. 背压（Pipe 满了写不动）
  5. 零拷贝（数据停留在 Pipe 池里）

ASP.NET Core / Kestrel / SignalR 全部用 Pipelines

1
2
3
4

// 看起来是异步
using var fs = new FileStream("data.bin", FileMode.Open);
byte[] buf = new byte[4096];
int read = await fs.ReadAsync(buf, 0, 4096);

1
2
3
4
5
6
7
8
9

实际行为：
  - 默认构造的 FileStream，ReadAsync 是"假异步"
  - 内部用一个线程池线程做同步 Read
  - 异步调用反而多了线程切换开销

为什么？
  - Windows 文件 IO 默认是同步的
  - 要真正异步需要 FILE_FLAG_OVERLAPPED + 完成端口
  - .NET 默认不开（兼容性、性能权衡）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// ✅ 真异步
using var fs = new FileStream(
    "data.bin",
    FileMode.Open,
    FileAccess.Read,
    FileShare.Read,
    bufferSize: 4096,
    options: FileOptions.Asynchronous   // ← 关键
);

int read = await fs.ReadAsync(buf, 0, 4096);
// 这才是真正的异步（Windows 用 IOCP，Linux 用 io_uring）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

FileOptions.Asynchronous 的效果：
  - Windows：内部用 OVERLAPPED + IOCP
  - Linux：内部用 io_uring（.NET 6+）
  - 不占用线程池线程
  - 大量并发 IO 时差距巨大

FileSteam 静态方法：
  File.OpenRead("...")          // 没开 Asynchronous
  File.Open("...", FileMode)    // 没开

  → 想要真异步，必须用完整 FileStream 构造

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

场景：1 个进程同时读 1000 个文件，每文件 1MB

  默认（假异步）：
    1000 个线程池线程阻塞
    CPU 跑满，实际 IO 不快
    → 12 秒

  FileOptions.Asynchronous（真异步）：
    0 个线程池线程阻塞
    IOCP / io_uring 工作
    → 2 秒

→ 6 倍差距，这只是开了个开关

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// 真异步下，单线程顺序读：
await fs.ReadAsync(buf);
await fs.ReadAsync(buf);
await fs.ReadAsync(buf);
// 比同步：
fs.Read(buf);
fs.Read(buf);
fs.Read(buf);
// 慢一点（每次有 IOCP 唤醒开销）

// 但高并发下，真异步完胜

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// 三层包装：加密 + 压缩 + 文件
using var fs = new FileStream("data.gz.enc", FileMode.Create);
using var gz = new GZipStream(fs, CompressionMode.Compress);
using var cs = new CryptoStream(gz, aes.CreateEncryptor(), CryptoStreamMode.Write);

byte[] data = Encoding.UTF8.GetBytes("Hello, World!");
cs.Write(data, 0, data.Length);

// 数据流：
//   Write → cs 加密 → gz 压缩 → fs 落盘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

图示：
  ┌─────────────────────┐
  │ CryptoStream         │
  │  - 加密              │
  └──────────┬──────────┘
             ▼
  ┌─────────────────────┐
  │ GZipStream           │
  │  - 压缩              │
  └──────────┬──────────┘
             ▼
  ┌─────────────────────┐
  │ BufferedStream       │
  │  - 缓冲              │
  └──────────┬──────────┘
             ▼
  ┌─────────────────────┐
  │ FileStream           │
  │  - 落盘              │
  └─────────────────────┘

1
2
3
4
5
6
7

using var fs = new FileStream(...);
using var gz = new GZipStream(fs, ...);
// gz.Dispose() 内部会调用 fs.Dispose()
// 所以只 using 外层就够

// 但很多人不知道这点
// 容易在 finally 里手动 dispose 所有层

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 假设你有一个"共享底层流"
using var fs = new FileStream(...);

// 包装两个装饰器，都接管 fs
using var cs1 = new CryptoStream(fs, enc1, Write);
using var cs2 = new CryptoStream(fs, enc2, Write);

cs1.Write(...);   // 内部调 fs.Write
cs2.Write(...);   // 也调 fs.Write！
// 实际写入是混乱的（fs 是有状态的）

// 正确做法：每个底层流只对应一个装饰器链

1
2
3
4
5
6
7
8
9

using var fs = new FileStream(...);
using var bs = new BufferedStream(fs, 8192);  // 8KB 缓冲

// 现代 FileStream 默认就有 bufferSize
// NetworkStream 默认 64KB Socket 缓冲
// → BufferedStream 在大多数情况下是冗余的

// 但 CryptoStream / GZipStream 没有 buffer
// → 包在它们外面有用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// ❌ 手写循环
public async Task CopyAsync(Stream src, Stream dst)
{
    byte[] buf = new byte[8192];
    int read;
    while ((read = await src.ReadAsync(buf, 0, 8192)) > 0)
        await dst.WriteAsync(buf, 0, read);
}

// ✅ 内置（已经做了优化）
await src.CopyToAsync(dst, bufferSize: 8192);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// 简化版
public virtual async Task CopyToAsync(Stream dest, int bufferSize, CancellationToken ct)
{
    byte[] buffer = ArrayPool<byte>.Shared.Rent(bufferSize);
    try
    {
        int read;
        while ((read = await ReadAsync(buffer, ct)) > 0)
            await dest.WriteAsync(buffer.AsMemory(0, read), ct);
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer);
    }
}

1
2
3
4
5

内置的优势：
  - 用 ArrayPool（零分配）
  - 自适应 bufferSize
  - Stream 重写时有优化路径（如 MemoryStream → MemoryStream 直接拷贝）
  - 取消支持

1
2
3
4
5
6
7
8
9

// ❌ 慢
await src.CopyToAsync(dst);

// ✅ 快（用底层 Windows API CopyFile）
if (src is FileStream fs1 && dst is FileStream fs2)
{
    // .NET Core 内部已经针对 FileStream 优化
    // 直接调 Windows CopyFileEx
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Stream 抽象的根本问题：
  1. 应用必须分配 buffer（byte[]）
  2. 应用必须循环 Read
  3. 应用必须处理"读不满"的情况
  4. 没有背压（写太快时 Stream 不阻塞）
  5. 单段 buffer（数据可能跨段）

  → 写一个高性能 HTTP 服务器，光是处理"读满 N 字节"就要 100 行代码

Pipelines 重新设计：
  1. Pipe 内部管理 buffer（池化）
  2. Pipe 自动累积数据
  3. 调用方一次拿到"已经够多"的数据
  4. Pipe 满了写不动（背压）
  5. ReadOnlySequence<byte> 支持多段

1
2
3
4
5
6
7
8
9

var pipe = new Pipe(new PipeOptions(
    pool: ArrayPool<byte>.Shared,
    readerScheduler: PipeScheduler.ThreadPool,
    writerScheduler: PipeScheduler.ThreadPool,
    pauseWriterThreshold: 1024 * 1024,    // 写暂停阈值（背压）
    resumeWriterThreshold: 512 * 1024));   // 写恢复阈值

PipeWriter writer = pipe.Writer;
PipeReader reader = pipe.Reader;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// 解析"4 字节长度 + N 字节 body"协议
async Task ProcessAsync(PipeReader reader)
{
    while (true)
    {
        ReadResult result = await reader.ReadAsync();
        ReadOnlySequence<byte> buffer = result.Buffer;

        while (TryReadMessage(ref buffer, out var message))
        {
            ProcessMessage(message);
        }

        // 告诉 reader：消费到哪，下次从哪开始
        reader.AdvanceTo(buffer.Start, buffer.End);

        if (result.IsCompleted) break;
    }
}

bool TryReadMessage(ref ReadOnlySequence<byte> buffer, out ReadOnlySequence<byte> message)
{
    if (buffer.Length < 4) { message = default; return false; }

    Span<byte> lengthBytes = stackalloc byte[4];
    buffer.Slice(0, 4).CopyTo(lengthBytes);
    int length = BitConverter.ToInt32(lengthBytes);

    if (buffer.Length < 4 + length) { message = default; return false; }

    message = buffer.Slice(4, length);
    buffer = buffer.Slice(4 + length);
    return true;
}

1
2
3
4
5

对比 Stream 版本：
  - 没有手动 buffer 分配
  - 没有手动"读满 4 字节"循环
  - 处理"半个消息"自动等下次数据
  - 多段 Sequence 天然支持

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// 从 Stream 创建 PipeReader
PipeReader reader = PipeReader.Create(stream, new StreamPipeReaderOptions(
    bufferSize: 4096,
    leaveOpen: false));

// 从 Stream 创建 PipeWriter
PipeWriter writer = PipeWriter.Create(stream, new StreamPipeWriterOptions(
    leaveOpen: false));

// 或者反过来：把 Pipe 当 Stream 用
Stream stream = pipe.Writer.AsStream();

1
2
3
4
5

ASP.NET Core 的请求体就是 PipeReader：
  HttpContext.Request.BodyReader : PipeReader
  HttpContext.Response.BodyWriter : PipeWriter

  → 不再是 Stream，而是 Pipeline

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// ❌ 流泄漏
public byte[] Read(string path)
{
    var fs = new FileStream(path, FileMode.Open);
    var ms = new MemoryStream();
    fs.CopyTo(ms);
    return ms.ToArray();   // fs 和 ms 都没 Dispose
}

// ✅ using
public byte[] Read(string path)
{
    using var fs = new FileStream(path, FileMode.Open);
    using var ms = new MemoryStream();
    fs.CopyTo(ms);
    return ms.ToArray();
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// ❌ 火并忘记（fire and forget）
public void BadWrite(Stream s, byte[] data)
{
    s.WriteAsync(data, 0, data.Length);   // ⚠️ 没 await
    // 方法立即返回，写还没完成
}

// ✅ await 或显式处理
public async Task WriteAsync(Stream s, byte[] data)
{
    await s.WriteAsync(data);
}

1
2
3
4
5
6
7
8

// ❌ 假异步
using var fs = File.OpenRead("data.bin");   // 默认 options
await fs.ReadAsync(buf);   // 实际是线程池阻塞

// ✅ 真异步
using var fs = new FileStream("data.bin", FileMode.Open, FileAccess.Read,
    FileShare.Read, 4096, FileOptions.Asynchronous);
await fs.ReadAsync(buf);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// ❌ 每次 new
public async Task<byte[]> ReadAsync(Stream s)
{
    byte[] buf = new byte[4096];   // ⚠️ GC 压力
    using var ms = new MemoryStream();
    int read;
    while ((read = await s.ReadAsync(buf)) > 0)
        ms.Write(buf, 0, read);
    return ms.ToArray();
}

// ✅ ArrayPool
public async Task<byte[]> ReadAsync(Stream s)
{
    byte[] buf = ArrayPool<byte>.Shared.Rent(4096);
    try
    {
        using var ms = new MemoryStream();
        int read;
        while ((read = await s.ReadAsync(buf.AsMemory(0, 4096))) > 0)
            ms.Write(buf, 0, read);
        return ms.ToArray();
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buf);
    }
}

// ✅✅ CopyToAsync（最简）
public async Task<byte[]> ReadAsync(Stream s)
{
    using var ms = new MemoryStream();
    await s.CopyToAsync(ms);
    return ms.ToArray();
}

1
2
3
4
5
6
7
8
9

// ❌ 假设 stream 可 Seek
stream.Position = 0;
stream.Read(...);

// ✅ 检查
if (stream.CanSeek)
    stream.Position = 0;
else
    throw new InvalidOperationException("Stream is not seekable");

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// ❌ 加密数据不完整
using var cs = new CryptoStream(ms, enc, CryptoStreamMode.Write);
cs.Write(data, 0, data.Length);
// 没有 cs.FlushFinalBlock() 或 Dispose → AES 填充没写

// ✅ Dispose 自动 flush
using (var cs = new CryptoStream(ms, enc, CryptoStreamMode.Write))
{
    cs.Write(data, 0, data.Length);
}   // ← Dispose 触发 FlushFinalBlock

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

[MemoryDiagnoser]
public class StreamBench
{
    private MemoryStream _stream;

    [GlobalSetup]
    public void Setup()
    {
        var data = new byte[1_000_000];
        new Random().NextBytes(data);
        _stream = new MemoryStream(data);
    }

    [Benchmark]
    public int ReadAll_Array()
    {
        _stream.Position = 0;
        byte[] buf = new byte[4096];
        int total = 0;
        int read;
        while ((read = _stream.Read(buf, 0, buf.Length)) > 0) total += read;
        return total;
    }

    [Benchmark]
    public async Task<int> ReadAllAsync_Array()
    {
        _stream.Position = 0;
        byte[] buf = new byte[4096];
        int total = 0;
        int read;
        while ((read = await _stream.ReadAsync(buf, 0, buf.Length)) > 0) total += read;
        return total;
    }

    [Benchmark]
    public async Task<int> ReadAllAsync_Pooled()
    {
        _stream.Position = 0;
        byte[] buf = ArrayPool<byte>.Shared.Rent(4096);
        try
        {
            int total = 0;
            int read;
            while ((read = await _stream.ReadAsync(buf.AsMemory(0, 4096))) > 0) total += read;
            return total;
        }
        finally
        {
            ArrayPool<byte>.Shared.Return(buf);
        }
    }

    [Benchmark]
    public async Task<int> ReadAll_CopyToAsync()
    {
        _stream.Position = 0;
        using var ms = new MemoryStream();
        await _stream.CopyToAsync(ms, 4096);
        return (int)ms.Length;
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

典型结果（.NET 8）：
  ReadAll_Array         : ~280 μs, 4096 B allocated
  ReadAllAsync_Array    : ~320 μs, 5 KB allocated
  ReadAllAsync_Pooled   : ~300 μs, 0 B allocated   ← 推荐
  ReadAll_CopyToAsync   : ~280 μs, 0 B allocated   ← 最简洁

观察：
  - CopyToAsync 性能与最优手写持平
  - ArrayPool 版几乎零分配
  - 普通 byte[] 分配每秒万次 → GC 噪音

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

按用途分类：

  文件：
    FileStream         - 文件 IO（默认 buffered）
    FileStream(FileOptions.Asynchronous) - 真异步
    UnmanagedMemoryStream - 内存映射文件 / 非托管内存

  网络：
    NetworkStream      - Socket 包装
    SslStream          - SSL/TLS 加密层
    AuthenticatedStream - 基类，可继承做认证

  内存：
    MemoryStream       - byte[] 包装
    ReadOnlyMemoryStream - 不可变切片
    RecyclableMemoryStream - Microsoft.IO.RecyclableMemoryStream 库，池化版

  管道：
    AnonymousPipeServerStream / ClientStream - 父子进程
    NamedPipeServerStream / ClientStream     - 命名管道

  装饰器：
    BufferedStream     - 缓冲
    CryptoStream       - 加密
    GZipStream / DeflateStream / BrotliStream - 压缩

  其他：
    Stream.Null        - 黑洞
    IsolatedStorageFileStream - 沙盒存储

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

默认：
  using var fs = new FileStream(path, FileMode.Open, FileAccess.Read,
      FileShare.Read, 4096, FileOptions.Asynchronous);

  → 读大文件 / 高并发必开 Asynchronous
  → 简单一次性读取：File.ReadAllBytesAsync（内部就是上面的封装）

需要 seek：
  ✅ FileStream 默认支持

需要内存映射：
  MemoryMappedFile.CreateFromFile(...)

1
2
3
4
5
6
7
8
9

默认：
  using var fs = new FileStream(path, FileMode.Create, FileAccess.Write,
      FileShare.None, 4096, FileOptions.Asynchronous);

  → 加 BufferedStream 收益不大（FileStream 已有 buffer）
  → FileOptions.WriteThrough 用于关键数据（绕过 OS 缓存，直接落盘）

追加：
  File.AppendAllTextAsync / AppendAllBytesAsync

1
2
3
4
5
6
7

服务器：
  Socket → NetworkStream → 用 PipeReader 包装
  → 高性能场景直接用 Pipelines API

客户端：
  HttpClient（已经用 Pipelines 内部）
  → 不要手动 new NetworkStream

1
2
3

写：CryptoStream → GZipStream → FileStream
读：FileStream → GZipStream → CryptoStream
注意 dispose 顺序（外层先 dispose，自动级联）

1
2
3
4

记住三句话：
  1. Stream 是"拉"模式 + "同步"基础，Pipelines 是"推"模式 + 背压原生
  2. FileStream 不开 Asynchronous 等于自废武功
  3. Stream.Read 返回值永远不能假设"读满"——这是抽象的代价