必须先有Database实例再调用gridfs_bucket()方法初始化；驱动仅在首次写入时自动创建fs.files/fs.chunks集合及索引，自定义bucket名需用GridFsBucketOptions.builder().bucket_name("uploads").build()，且须确保对应集合存在，否则上传失败。
如何初始化 GridFS Bucket 实例
必须先有 Database 实例，再调用 gridfs_bucket() 方法；驱动不会在初始化时创建集合或索引，而是在第一次写入时才自动建 fs.files 和 fs.chunks 并加索引。
常见错误是传错参数类型——gridfs_bucket() 接收的是 Option<gridfsbucketoptions></gridfsbucketoptions>，不是字符串或自定义结构体。若要用自定义 bucket 名（比如 "uploads"），得构造 GridFsBucketOptions::builder().bucket_name("uploads").build()。
- 默认行为：使用
"fs"前缀 → 集合为fs.files/fs.chunks - 自定义前缀后，务必确认服务端 MongoDB 确实存在对应集合，否则首次上传会失败（不是静默忽略）
- 不要把
Client直接传给gridfs_bucket()，它只认Database
上传文件时如何避免内存暴涨和读取错位
上传必须用 UploadFromStream，且第二个参数是 impl AsyncRead + Unpin，不是 &File 或 *File。直接传 File 会导致文件指针位置混乱，尤其在复用同一文件句柄多次上传时，内容可能为空或截断。
正确做法是包装成带缓冲的流：
- 小文件（BytesReader::new(data)（来自
bytescrate） - 大文件：用
BufReader::with_capacity(64 * 1024, file)，显式控制缓冲区大小 - HTTP 请求体：直接传
req.body_mut()（前提是框架支持AsyncRead）
别忽略 UploadOptions 中的 chunk_size_bytes：默认 255KB，对视频或归档包来说太小，频繁分块会增加网络 round-trip；设为 1MB–4MB 更适合大文件，但需权衡单次 write 的稳定性。
下载文件时怎么安全读取并防止连接泄漏
下载必须用 open_download_stream() 获取 GridFSDownloadStream，不是查 files 集合再手动拼 chunks。后者要自己处理块序号、校验、EOF 判断，极易出错。
open_download_stream() 支持两种查找方式：
- 用
ObjectId：精准、快、不依赖索引，推荐用于内部 ID 传递场景 - 用文件名：调用
open_download_stream_by_name()，但注意它只返回同名文件的最新版本（按uploadDate降序），且字段值区分大小写
流对象实现了 AsyncRead，但**必须显式关闭**：Rust 驱动不依赖 drop 自动清理底层连接，未 close 可能导致连接池耗尽。实际使用中应配合 tokio::io::copy 或 read_to_end，并在作用域末尾确保 stream.close().await 被调用（或用 DropGuard 封装）。
ChunkSizeBytes 设得太大会不会影响并发上传稳定性
会。虽然增大 chunk_size_bytes 可减少 chunk 文档数量、降低索引压力，但它同时增加了单次 write 操作的数据体积和超时风险。MongoDB 默认 socket timeout 是 30 秒，若 chunk 大于 10MB 且网络抖动，容易触发 Timed out waiting for response 错误。
真实项目中建议按文件类型分档设置：
- 图片/文档类（
- 视频/备份包（>100MB）：2MB–4MB，并配
WriteConcern::majority().w_timeout(60_000) - 绝对不要设 >8MB —— 这已超出 MongoDB 单文档 16MB 上限，驱动会 panic
最易被忽略的一点：不同 bucket 的 chunk_size_bytes 是独立配置的，改了一个不影响其他；但一旦某个 bucket 完成首次上传，其 chunk 大小就固定了，后续上传必须保持一致，否则读取时会解包失败。
