GridFS 本身不支持多文档事务和区域感知，其“多中心读写加速”依赖 MongoDB 分片集群的 zone 配置、fs.files 与 fs.chunks 的正确分片（片键需匹配）、以及驱动端 readPreference 设置；所有操作均转化为对这两个集合的 CRUD。
GridFS 本身不支持多文档事务，也不内置区域感知或分片路由逻辑——所谓“多中心读写加速”必须靠 MongoDB 底层分片集群 + 副本集地理标签（zone）+ 驱动端读偏好（readPreference）协同实现，不是 GridFS 自身能力。
GridFS 查询实际走的是底层集合的读操作
GridFS 只是规范，底层对应两个集合：fs.files 和 fs.chunks。所有文件读写最终转化为对这两个集合的 CRUD 操作。因此，GridFS 的“就近访问”完全依赖于：
- MongoDB 分片集群是否已按地理位置配置
zone和zone sharding规则 -
fs.files和fs.chunks是否被正确分片（注意：fs.chunks必须以files_id为片键，且与fs.files使用相同分片策略，否则跨片查询无法避免） - 客户端驱动是否显式设置
readPreference=nearest或带maxStalenessSeconds的primaryPreferred
分片键选错会导致 GridFS 跨地域拉取 chunks
默认情况下，GridFS 不自动分片；你必须手动对 fs.files 和 fs.chunks 启用分片，并确保片键设计匹配访问模式：
-
fs.files推荐片键：{ _id: "hashed" }（均衡分布）或{ region: 1, _id: 1 }（若业务能写入时带上region字段） -
fs.chunks片键必须为{ files_id: 1, n: 1 }，且files_id必须与fs.files._id类型一致（通常是ObjectId），否则 chunk 无法和 file 元数据落在同一分片 - 如果只分片
fs.files而忽略fs.chunks，读一个大文件时会触发大量跨分片 chunk 查询，延迟飙升
区域感知需靠 zone + tag-aware sharding + 应用层配合
MongoDB 不会自动把用户请求路由到“最近机房”，必须显式配置：
- 给每个分片副本集成员打标签，例如：
{ "region": "shanghai" }、{ "region": "singapore" } - 为
fs.files集合创建 zone：如shanghai_zone覆盖{ region: "shanghai" }，并绑定到对应分片 - 写入文件时，在
fs.files文档中写入region字段（或其它可分片字段），驱动才能将该文件及其所有 chunks 路由到目标区域 - 读取时，用
find({ region: "shanghai" })+readPreference=primaryPreferred，才可能命中本地分片
容易被忽略的关键点
很多团队卡在“配置了 zone 却没效果”，根本原因是：
-
fs.chunks没分片，或片键不是{ files_id: 1, n: 1 }→ 所有 chunks 都落在同一个分片，彻底失去地理局部性 - 写入文件时没传自定义元数据（如
region），导致无法按 zone 路由 → 文件随机落到任意分片 - 驱动连接字符串没加
?readPreference=nearest，或应用层硬编码了readPreference=primary - 误以为 GridFS API 有
location参数 —— 实际上所有 GridFS 方法（如gridFSBucket.openDownloadStream()）都不接受地域参数，全靠底层集合行为和驱动配置
