mongodb 8.0 中 gridfsbucket 仍为官方推荐 api，但需注意：初始化不再自动创建索引，须手动补全 fs.files 和 fs.chunks 标准索引；chunksizebytes 设置影响性能与内存；opendownloadstreambyid() 要求显式 objectid 实例，不自动转换字符串；delete() 和 rename() 非原子操作，存在孤儿块风险。
MongoDB 8.0 中 GridFS 的使用方式与 4.4+ 版本基本一致，GridFSBucket 仍是官方推荐的 API；它没被移除，也没新增语法糖，但有几个关键点必须注意——尤其是索引行为、默认 chunkSize 和驱动兼容性。
GridFSBucket 初始化时 bucketName 不再默认创建索引？
MongoDB 8.0 驱动（如 Node.js v6.7+）在调用 db.selectGridFSBucket() 时，**不会主动创建 fs.files 和 fs.chunks 的索引**，除非存储桶为空且首次写入。这意味着：如果手动删过索引、或从旧版本迁移过来且未触发过写入，find() 或 openDownloadStream() 可能因缺失索引而显著变慢，甚至超时。
- 检查索引是否存在：
db.fs.files.getIndexes()和db.fs.chunks.getIndexes() - 缺失时手动补上（标准索引）：
db.fs.files.createIndex({ "filename": 1 })、db.fs.chunks.createIndex({ "files_id": 1, "n": 1 }) - 注意：
bucketName自定义后，集合名会变成mybucket.files和mybucket.chunks，索引也要对应创建
chunkSizeBytes 设置影响读写性能和内存占用
默认 chunk 大小仍是 255 * 1024（255 KiB），但 MongoDB 8.0 对大文件流式上传更敏感——若 chunk 过小（如设为 16 * 1024），会导致 fs.chunks 文档数量暴增，写放大严重；若过大（如 2 * 1024 * 1024），单次网络传输失败会重传整个 chunk，且 openDownloadStream() 跳转（range query）精度下降。
- 视频/音频类文件建议保持默认或略调高（
512 * 1024） - 日志或文本类小块高频写入场景，可降至
64 * 1024，但需确认fs.chunks索引能支撑高并发 insert - 设置方式：
selectGridFSBucket({ chunkSizeBytes: 524288 })
openDownloadStreamById() 在 ObjectId 字符串输入时容易报错
8.0 驱动对 _id 类型校验更严格：传入字符串形式的 ObjectId（如 "65a1b2c3d4e5f67890abcdef"）时，openDownloadStreamById() 不再自动转换，直接抛出 CastError 或空流。
- 必须显式构造 ObjectId：
new ObjectId("65a1b2c3d4e5f67890abcdef") - 若从 URL 参数接收 ID，务必先验证格式：
ObjectId.isValid(id)再转换 - 元数据查询（如按 filename）仍可用字符串，不受影响
不支持多文档事务，但 delete() 操作有隐式一致性风险
GridFS 的 delete() 方法看似原子，实际是先删 fs.files 文档，再删关联的 fs.chunks 文档。MongoDB 8.0 仍未支持跨集合事务，因此若删除中途崩溃，可能出现“元数据已删、chunks 残留”的脏状态。
- 生产环境务必搭配定期清理脚本：
db.fs.chunks.deleteMany({ files_id: { $nin: db.fs.files.find().map(f => f._id) } }) - 避免在高并发删除场景下依赖单次
delete()，建议加分布式锁或改用 soft-delete（标记 + TTL） -
rename()同理，也是两步操作，不保证中间态不可见
真正麻烦的不是 API 调用本身，而是索引缺失导致的静默性能退化，以及 ObjectId 类型处理这种“看起来该自动转、其实不转”的细节——它们不会报错，但会让流卡住或返回空内容，排查起来特别耗时间。
