最稳妥的方式是使用 BlobClient.DownloadTo(Stream destination)，SDK 自动分块拉取并写入目标流，避免内存溢出；若需可寻址流，仅小文件可用 MemoryStream 包装 DownloadContentAsync 结果。
用 BlobClient.DownloadTo 直接写入流最稳妥
多数人想“获取文件流”其实是为后续处理（比如传给 Image.Load、StreamReader 或 Web API 响应），但直接调 BlobClient.DownloadAsync 返回 Response 再取 .Value.Content 容易踩内存坑——它返回的是整个 blob 的 Stream，但默认是 NonSeekableStream，不支持 Seek 或反复读。
更稳的做法是让 SDK 帮你把内容落盘或写进已有流：
-
BlobClient.DownloadTo(Stream destination)：传入MemoryStream或FileStream，SDK 自动分块拉取、写入，不爆内存 - 如果必须返回可 seek 的流，用
new MemoryStream(await client.DownloadContentAsync().Value.Content.ToArray())，但只适用于小文件（ - 大文件别用
DownloadContentAsync，它会把整个 blob 加载进内存，OOM 风险高
BlobClient.OpenReadAsync 返回的流不能随便 Seek
这个方法看着像“打开流”，实际返回的是一个只读、不可寻址、单次消费的流。常见错误是拿到后立刻 stream.Position = 0 或 stream.Seek(0, SeekOrigin.Begin)，结果抛 NotSupportedException。
原因：Azure SDK 默认用 HTTP Range 请求 + 管道流实现，底层没有缓冲，也不维护位置状态。
- 需要多次读？先
DownloadTo(new MemoryStream())得到可 seek 的副本 - 只想流式处理（如解压、转码）？用
OpenReadAsync没问题，但必须顺序读完，别 rewind - .NET 6+ 可配合
Stream.CopyToAsync(otherStream)直接转发，避免中间内存拷贝
下载时控制并发和超时，否则小文件也容易失败
默认配置下，BlobClient 的 DownloadTo 或 OpenReadAsync 在网络抖动或 blob 较大时容易卡住或超时，报错类似 RequestFailedException: The operation was canceled. 或 TimeoutException。
这不是代码写错了，而是客户端默认超时太短（通常 100 秒），且没设重试策略。
- 初始化
BlobClient时传入BlobClientOptions，改Transport层超时：options.Retry.MaxRetries = 3; options.Transport = new HttpClientTransport(new HttpClient { Timeout = TimeSpan.FromMinutes(5) }); - 大文件建议开并行下载：
DownloadTo(..., new BlobDownloadToOptions { ParallelTransferOptions = new ParallelTransferOptions { MaximumConcurrency = 4 } }) - 别依赖
CancellationToken来“取消大下载”——HTTP 连接可能已发出去，cancel 只能中断本地等待，服务端还在传
从 SAS URL 下载时，BlobClient 构造方式不同
如果你只有 SAS token（比如前端传来的临时链接），不能用 new BlobServiceClient(connectionString)，得用带 URI 的构造函数，否则会提示 AuthenticationFailed 或 403。
- 正确方式：
var client = new BlobClient(new Uri("https://xxx.blob.core.windows.net/container/file.txt?sv=...")); - SAS URL 必须完整包含协议、host、路径和 query string，缺一不可
- 这种 client 不支持管理操作（如
DeleteAsync），仅限下载；若需上传/删，必须回退到用 Account Key 或 MSI 认证的BlobServiceClient
Blob 流的本质是 HTTP 响应体，不是本地文件句柄。所有“获取流”的操作，背后都是发起一次 GET 请求，区别只在于 SDK 是否帮你缓冲、分块、重试。真正难的从来不是怎么写那行代码，而是想清楚你要的是“一次消费的管道”，还是“可反复读的副本”，再选对 API。
