必须在创建 gridfsbucket 实例时指定 chunksizebytes，运行时无法修改；该值为 bucket 级属性，不同 bucket 可设不同大小，须为正整数且 ≤8mb，否则写入失败。
必须在创建 GridFSBucket 实例时指定 ChunkSizeBytes，运行时无法修改已存在的 bucket 的块大小。
创建 bucket 时显式设置 ChunkSizeBytes
GridFS 块大小不是数据库级配置，而是每个 bucket 的实例属性。不同 bucket 可以使用不同 chunk 大小，互不影响。
- .NET Driver 中通过
GridFSBucketOptions.ChunkSizeBytes设置，例如：var options = new GridFSBucketOptions { ChunkSizeBytes = 262144 }; // 256KB<br>var bucket = new GridFSBucket(database, options); - Java Driver（v4.7+）中用
GridFSBuckets.create(database, bucketName, options)，其中options是GridFSBucketSettings实例，调用chunkSizeBytes(262144) - Python PyMongo 中传入
chunk_size_bytes=262144参数：GridFSBucket(db, chunk_size_bytes=262144) - 注意：该值必须是正整数，且不能超过 8MB（即 8388608），否则写入会失败并报错
Document too large
为什么不能改已有 bucket 的 chunk 大小？
因为 chunk 大小决定了文件如何被切分、存储到 fs.chunks 集合中——它直接编码在每条 chunk 文档的 length 字段和整体结构里。一旦文件已上传，其所有 chunk 就按原始大小写入，驱动读取时也严格按该大小解析流。
- 试图用新 chunk 大小读旧文件，会导致
Stream.Read返回异常字节数或校验失败 - 元数据文档（
fs.files）中记录的chunkSize字段是只读快照，修改它不会改变实际 chunk 存储格式 - 若真需调整，只能重新上传文件，并确保前端 Range 请求与新 chunk 边界对齐（比如设为 256KB 后，前端按 1MB 分片就刚好跨 4 个 chunk）
ChunkSizeBytes 设多少才合理？
没有全局最优值，取决于你的访问模式和部署架构：
- 单机或小集群 + 按用户隔离文件 → 保持默认 256KB 或设为 512KB，平衡 I/O 和元数据量
- 分片集群 + 文件无强业务键（如公开资源池）→ 设为 1MB（1048576）以上，降低
fs.chunks文档总数，缓解元数据压力 - 前端做固定粒度 Range 请求（如每次请求 1MB 视频片段）→ 必须设为该粒度的整数倍（如 256KB、512KB、1MB），否则驱动会跨 chunk 读取、拼接、裁剪，白白增加内存和延迟
- 绝对不要设 >8MB：WiredTiger 单文档硬上限 16MB，但 chunk 文档还需携带
_id、files_id、n、data等字段，超限直接写入失败
真正容易被忽略的是：chunk 大小一旦选定，就和你的前端分片策略、分片集群的共置设计、甚至 CDN 缓存命中率绑死。改一个参数，往往要前后端+DBA 一起对齐，而不是只改一行代码。
