默认255kb在大文件场景下拖垮读取性能，因其导致50mb文件生成约200个chunk，引发cpu高频反序列化、机械硬盘200次随机寻道（等待2–4秒）、node.js驱动高频buffer拷贝与gc压力。
chunkSize 调大能显著降低 CPU 和磁盘 I/O 开销，但必须结合访问模式、硬件类型和分片设计一起调，单独改参数反而可能让性能更差。
为什么默认 255KB 在大文件场景下会拖垮读取性能
GridFS 默认 chunkSizeBytes 是 255KB（即 261120 字节），这个值在小文件或单机测试中没问题，但一到大文件（如视频、模型权重、高清图）就暴露三个硬伤：
- 每个 chunk 是独立 BSON 文档，驱动要逐个反序列化
_id、n、data字段——50MB 文件用默认大小会生成约 200 个 chunk，CPU 大量耗在解析上 - 机械硬盘上频繁随机寻道：200 次磁盘 I/O 意味着至少 2–4 秒纯等待，SSD 也扛不住高并发小块读
- 流式读取时 Buffer 拷贝放大：Node.js 驱动默认把每个 chunk 先完整读进内存再 pipe，小 chunk 导致高频
Buffer.concat()和 GC 压力
验证方式：在下载逻辑里加计数器，比如 stream.on("data", () => chunkCount++)，若平均 10MB 文件触发 > 50 次回调，基本可判定 chunk 太小。
chunkSize 设置必须匹配你的硬件和访问路径
没有“万能值”，关键看你是怎么读、在哪读、读什么：
- 机械硬盘 + 单次全读（如导出备份）：直接设
chunkSizeBytes: 4 * 1024 * 1024（4MB），chunk 数量降为原来的 1/16，I/O 次数和解析开销同步骤降 - SSD + 前端 Range 请求（如视频跳播）：优先对齐前端分片粒度，比如前端按 1MB 分片，就设
chunkSizeBytes: 262144（256KB），保证每 4 个 chunk 刚好凑成 1MB，避免跨 chunk 裁剪 - 分片集群环境：chunkSize 过大会加剧分布不均——若
fs.files按user_id分片，但用户上传文件大小差异极大（有人传 1MB 图，有人传 500MB 视频），大 chunk 会让某些分片堆积更多数据。此时建议固定为 1MB～2MB，并确保fs.files的分片键能均匀打散 - 绝对不要设 > 8MB：WiredTiger 单文档上限 16MB，chunk 还要带 BSON 元数据，超限写入直接报错
Document too large
已有数据无法在线修改 chunkSize，重传是唯一可靠方案
GridFS 的 chunkSizeBytes 是写入时定死的，存在 fs.files.chunkSize 字段里，但驱动读取时不校验它，只按实际存储的 fs.chunks 文档来拼接。这意味着：
- 改
fs.files.chunkSize字段毫无作用，驱动完全忽略 - mongodump/mongorestore 不会重切 chunk，原样复制旧结构
- 想真正生效，必须用新
chunkSizeBytes创建GridFSBucket实例，然后重新上传文件——哪怕只是get出来再put回去 - 如果业务已上线且不能停写，可用双写过渡：新上传走新 bucket，老文件按需迁移，通过应用层路由区分
最容易被忽略的一点：chunkSize 影响的不只是“读多快”，更是“第一次加载是否让用户等得想关页面”。哪怕 HTTP 缓存配置完美，首次读取慢，用户刷新或切页，缓存就彻底失效。所以 chunkSize 是缓存策略能落地的前提，不是可选项。
