结论：MongoDB 5.0 升级到 6.0 时，GridFS 本身不涉及格式变更或弃用，但升级路径、驱动兼容性和元数据处理方式必须严格对齐，否则会出现文件读取失败、fs.files 和 fs.chunks 集合查询异常、甚至 mongorestore 后文件不可访问等问题。
直接说结论：MongoDB 5.0 升级到 6.0 时，GridFS 本身不涉及格式变更或弃用，但升级路径、驱动兼容性和元数据处理方式必须严格对齐，否则会出现文件读取失败、fs.files 和 fs.chunks 集合查询异常、甚至 mongorestore 后文件不可访问等问题。
升级必须走 5.0 → 6.0 的线性路径，不能跳过中间版本
官方明确禁止从 5.0 直接升级到 6.0 以外的任意版本（比如 5.0 → 7.0），但更关键的是：即使目标是 6.0，也必须确认当前部署已稳定运行在 5.0，并且 featureCompatibilityVersion 已设为 "5.0"。若仍停留在 "4.4" 或更低，GridFS 的元数据字段（如 uploadDate 类型、metadata 的嵌套结构）可能被旧版驱动写入非标准 BSON 类型，6.0 的新驱动在解析时会静默忽略或报 InvalidBSON 错误。
- 检查当前 FCV：
db.adminCommand({getFeatureCompatibilityVersion: 1}) - 升级前务必执行：
db.adminCommand({setFeatureCompatibilityVersion: "5.0"})，并等待所有节点同步完成 - FCV 不匹配时，
mongodump备份的fs.*集合可能丢失_id类型信息，导致mongorestore后GridFSBucket.openDownloadStream()找不到文件
驱动程序必须同步升级，尤其注意 GridFSBucket 的构造参数变化
MongoDB 6.0 驱动（如 Node.js 的 mongodb@6.x）默认启用更严格的类型校验，而旧版驱动（如 mongodb@4.x）写入的 fs.chunks 中 data 字段可能为 BinData(0, "...")，新驱动尝试解码时若未显式指定 disableOversizeCheck: true，会因 chunk 超过 16MB（尽管实际不可能）而抛出 RangeError。
- Node.js 示例中必须显式传参：
new GridFSBucket(db, { bucketName: 'fs', disableOversizeCheck: true }) - Python 的
pymongo4.0+ 默认禁用 oversize 检查，但若代码里手动设置了chunk_size_bytes为非 255KB 的值（如 1MB），需确认该值在 5.0 写入时已被实际使用——6.0 驱动不会自动适配历史 chunk 大小，读取时仍按默认 255KB 拆分，导致内容错位 - Java 驱动
mongo-java-driver 4.11+引入了GridFSFindIterable的新游标行为，老代码用iterator().next()可能因元数据字段缺失（如缺少length）而空指针
fs.files 和 fs.chunks 集合不能直接用 mongorestore 替换，必须走驱动层迁移
很多人试图用 mongodump --db myapp --collection fs.files --collection fs.chunks 备份后直接 mongorestore 到 6.0 实例，结果文件能列出来但打不开。根本原因是：6.0 的 GridFSBucket 在查询时依赖 _id 字段的 ObjectId 类型一致性，以及 files_id 在 chunks 中必须与 files._id 完全匹配（包括字节序、时间戳精度）。而 mongorestore 在跨版本恢复时可能重写 _id 或截断高精度时间戳。
- 安全做法：用 5.0 驱动连接旧库，逐个调用
bucket.find().toArray()获取文件列表，再用 6.0 驱动的bucket.openUploadStream()重写一遍，确保元数据和 chunk 结构符合新规范 - 若文件量大，可跳过内容重写，仅修正元数据：
db.fs.files.updateMany({}, {$set: {uploadDate: {$toDate: "$uploadDate"}}})，因为 5.0 存储的Date可能被误存为字符串或毫秒数 - 切勿手动修改
fs.chunks的n字段顺序——6.0 驱动严格校验连续编号，缺一个就会中断流式读取
真正容易被忽略的点是：GridFS 不是“只要集合存在就能用”的黑盒。它高度依赖驱动与服务端在 chunk 拆分逻辑、元数据字段语义、错误恢复机制上的精确对齐。一次看似干净的版本升级，可能让三年前上传的 PDF 突然无法下载——问题往往不出在大文件本身，而出在第 17 个 chunk 的 files_id 字段少了一个字节的 ObjectId 校验。
