GridFS分片需手动配置：fs.chunks必须用{files_id:"hashed"}分片，fs.files推荐{_id:"hashed"}；已存数据的集合无法直接shard，须清空重导；上传须先写chunks后写files，且chunk按n字段严格递增。
支持，但不是开箱即用的自动分片——fs.files 和 fs.chunks 必须手动分片，且必须在写入任何文件前完成。
为什么 sh.shardCollection() 对已存在的 GridFS 集合会失败
GridFS 本身只是两个普通集合（fs.files 和 fs.chunks），MongoDB 不识别它们的“GridFS 语义”，只按普通集合规则处理分片。一旦有数据写入：
-
sh.shardCollection()会直接报错：Cannot shard collection with existing data unless it has a shard key index - 即使你提前建了索引，只要集合非空，shard 操作仍被拒绝（MongoDB 5.0+ 也未放宽此限制）
- 强行清空再分片 → 重导数据，是唯一补救路径，但生产环境代价极高
fs.chunks 必须用 { files_id: "hashed" } 分片
这是性能生死线。用错分片键会导致读取一个文件时跨多个分片拉取 chunk，延迟翻倍甚至超时：
-
files_id是外键，指向fs.files._id；哈希后能保证同一文件所有chunk落在同一分片（co-location） - 若误用
{ _id: "hashed" }，一个文件的几十个 chunk 会散落在不同分片，GridFSBucket.openDownloadStream()内部需发起多次跨分片查询 - 分片命令必须显式执行：
sh.shardCollection("mydb.fs.chunks", { files_id: "hashed" })
fs.files 的分片键选 _id 还是业务字段
推荐 { _id: "hashed" }，除非你有强一致的范围查询需求：
-
{ _id: "hashed" }：写入均匀、无热点，适合大多数场景；filename查询靠额外索引支撑 -
{ "metadata.user_id": 1 }：MongoDB 5.0+ 支持，但要求该字段写入时必填、不可为空、值稳定；否则空值聚集导致分片倾斜 - 切勿用
{ filename: 1 }做分片键——文件名重复率高，极易产生 chunk 热点
客户端上传顺序不能乱：chunks 全写完，再写 files
GridFS 驱动（如 Node.js 的 mongodb 包）靠 fs.files 文档是否存在来判断文件是否“就绪”。顺序颠倒会引发竞态问题：
- 先写
fs.files→ 驱动可能立即尝试读取，但对应fs.chunks尚未写入，返回空或损坏文件 - chunk 写入必须严格按
n字段递增（0, 1, 2…），不能依赖服务端生成；推荐用Math.floor(offset / chunkSize)计算 - 不要用
insertMany批量写 chunk——网络层不保序；应串行insertOne或用ordered: false并逐个检查result.upsertedCount
最容易被忽略的一点：分片配置不是一次设置就一劳永逸的事。如果后续新增分片节点，fs.chunks 的哈希分片会自动再平衡，但 fs.files 的分片行为取决于你当初选的键——选错就只能导出重建。
