GridFS 默认 chunkSize 是 255KB（261120 字节），由规范固定，所有官方驱动遵循；该值是兼顾 BSON 限制与 I/O 效率的历史折中；可通过 chunkSizeBytes 覆盖，但仅影响新文件。
GridFS 默认 chunkSize 是多少？
默认是 255KB（即 261120 字节），不是常见的 256KB 或 1MB。这个值写死在 GridFS 规范里，所有官方驱动（Python、Java、Node.js 等）都遵循它。
为什么是 255KB？历史原因：早期 BSON 协议对某些字段长度有隐式限制，255KB 能稳定避开边界问题，同时兼顾网络传输和磁盘 IO 效率。它不是“最优”，而是“足够稳”的折中选择。
- 可通过
chunkSizeBytes参数在初始化GridFSBucket或GridFS实例时覆盖（比如设为512 * 1024） - 修改后只影响新上传的文件；已有文件的 chunk 大小不变，
fs.files.chunkSize字段仍保留原值 - 过小（如 4KB）会导致
fs.chunks文档数量暴增，索引膨胀、查询变慢 - 过大（如 2MB）可能触发单文档写入超时，尤其在网络不稳或副本集同步延迟时
怎么查当前文件实际用的 chunkSize？
别猜，直接查 fs.files 集合里的元数据。每个文件独立记录自己被切分时用的大小，不受后续 bucket 配置变更影响。
例如用 mongosh 查一个叫 report.pdf 的文件：
db.fs.files.findOne({ filename: "report.pdf" }, { projection: { chunkSize: 1, length: 1, _id: 1 } })返回里 chunkSize 字段就是它的真实分块大小——常见值是 261120，但也可能是你自定义的其他值。
- 注意：
fs.chunks文档本身不存chunkSize，只靠files_id关联回fs.files才能还原上下文 - 如果查不到该文件，说明它根本没走 GridFS（比如文件 ≤16MB，被当普通二进制字段存了）
- 批量检查时，别用
.count()，改用.estimatedDocumentCount()，避免全表扫描
改 chunkSize 会影响已存文件吗？
完全不影响。GridFS 的 chunk 大小是**写入时决定、读取时还原**的静态属性。改配置只改变后续上传行为。
这意味着：
- 同一个 bucket 里可能混着不同
chunkSize的文件（比如老文件用 255KB，新文件用 1MB） -
fs.chunks集合里所有文档结构一致，但它们所属文件的逻辑块大小可能各不相同 - 备份/迁移时无需特殊处理 chunkSize 差异，MongoDB 读取时自动按各自
fs.files.chunkSize拼接
真正容易被忽略的是：chunkSize 修改后，应用层上传逻辑若没同步更新（比如前端预估分片数、断点续传校验），就可能因块数量计算错误导致校验失败或重传错位。
