GridFS在.NET Core中需用GridFSBucket的OpenDownloadStreamAsync获取可读流，而非FindAsync；支持ObjectId或filename查找，但后者区分大小写且仅返回最新版本；流必须using释放，避免内存泄漏。
GridFS在.NET Core里不是直接用Find查出来的
GridFS本质是把大文件拆成chunks和files两个集合存的，你不能像查普通文档那样用FindAsync去捞文件内容。.NET官方驱动没提供“一键读取文件流”的高层API，得靠GridFSBucket来协调两集合、拼回原始数据。
- 必须先初始化
GridFSBucket，传入数据库实例和可选配置（比如自定义bucketName） -
OpenDownloadStreamAsync才是正确入口，它返回GridFSDownloadStream<T>，这才是能读的流 - 别试图用
FindAsync查files集合然后手动读chunks——顺序、校验、分片大小都得自己处理，极易出错
OpenDownloadStreamAsync要传ObjectId还是filename？
两种方式都支持，但行为不同，选错会导致查不到或读错文件：
- 用
ObjectId：精准匹配，适合你知道文件ID（比如从files._id拿到的值），速度最快，不依赖索引 - 用
filename：会查files集合里filename字段，注意它默认**区分大小写**，且只返回同名的最新版本（按uploadDate倒序），旧版本会被跳过 - 如果文件名含特殊字符（如空格、中文），确保MongoDB驱动已正确编码；更稳妥的做法是统一用
ObjectId，避免字符串匹配歧义
读取时容易忽略的异常和资源释放
GridFSDownloadStream是IDisposable，而且内部持有网络连接和缓冲区，不及时释放会导致内存泄漏或连接耗尽。
- 必须用
using包裹流，或者显式调用DisposeAsync()——哪怕只是读前几KB就break了 - 常见错误：
await stream.CopyToAsync(output)中途抛异常，using没生效，流没关 - 别用
stream.Read循环读取到0为止——GridFSDownloadStream的Read可能阻塞或返回不完整字节，优先用CopyToAsync或ReadAsync配合Memory<byte> - 超时设置：通过
GridFSBucketOptions里的ReadPreference和底层MongoClientSettings控制，不是流本身的参数
完整读取示例（带错误防护）
以下是最简可用路径，覆盖ID查找、流复制、异常清理：
var bucket = new GridFSBucket(database);
try
{
using var stream = await bucket.OpenDownloadStreamAsync(objectId); // 或 .OpenDownloadStreamByNameAsync("report.pdf")
using var fileStream = File.Create("downloaded.pdf");
await stream.CopyToAsync(fileStream);
}
catch (GridFSFileNotFoundException)
{
// 文件不存在，不是MongoException也不是IOException
}
catch (OperationCanceledException)
{
// 超时或取消令牌触发
}
注意GridFSFileNotFoundException是驱动特有异常，得单独捕获；其他IO异常走通用路径就行。真实场景中，文件名/ID来源不可信时，务必加try/catch，别让一次读取失败拖垮整个HTTP请求。
最麻烦的其实是并发读同一文件——GridFS本身没锁机制，多个请求同时OpenDownloadStreamAsync没问题，但你自己在上层做缓存或预热时，得小心竞态条件。这个点没人提，但线上出过问题。
