必须在初始化GridFSBucket时传入chunkSizeBytes参数（如{chunkSizeBytes: 1024*1024}），单位为字节，且需为256整数倍；该配置仅对新上传文件生效，不能动态修改或通过openUploadStream设置。
直接在创建 GridFSBucket 实例时传入 chunkSizeBytes 参数即可生效，无需改服务端配置、不涉及分片集群的 config.settings —— 那是另一个维度的“chunk”，和 GridFS 无关。
上传时怎么指定 chunkSizeBytes？
必须在初始化 GridFSBucket 时传入，不是上传单个文件时设置。驱动只认 bucket 级别的配置，openUploadStream() 的 options 里没有 chunkSizeBytes 这个字段。
-
chunkSizeBytes是GridFSBucket构造函数的第二参数，类型为 number（字节） - 例如设为 1MB：
new GridFSBucket(db, { chunkSizeBytes: 1024 * 1024 }) - 设为 4MB：
new GridFSBucket(db, { chunkSizeBytes: 4 * 1024 * 1024 }) - 值必须是 256 的整数倍（MongoDB 内部校验），但实际建议用 1024 的幂次（如 256KB/512KB/1MB/4MB）
为什么不能上传时动态改 chunk 大小？
因为 GridFS 的元数据（fs.files 文档）里 chunkSize 字段是写死的，它决定了后续所有 fs.chunks 文档如何切分、如何拼接。驱动在 openUploadStream() 时就根据这个值分配 buffer、计算 offset，中途无法切换。
- 试图在
uploadStream.write()里“覆盖” chunk 大小，会直接报错或导致读取乱码 - 已有文件的
chunkSize元数据不可变更：改files集合里的字段，驱动读取时仍按原大小去 fetchchunks，必然失败 - 所谓“重新上传”是指删旧文件 + 用新 bucket 实例上传，不是 patch 元数据
chunkSizeBytes 设多大才不踩坑？
没有全局最优值，得看你的硬件瓶颈在哪——机械硬盘怕随机寻道，SSD 怕内存缓冲溢出，弱网环境怕单 chunk 超时。
- HDD 场景（如 NAS、旧服务器）：优先试
1024 * 1024（1MB），避免默认 255KB 引发 40+ 次寻道 - 千兆内网 + SSD：
512 * 1024（512KB）更均衡，兼顾传输稳定性和 IOPS 压力 - 上传失败率高（尤其移动端）：下调到
128 * 1024（128KB），降低单次网络超时概率 - 别盲目上 4MB：Node.js 驱动默认 socket timeout 是 30s，带宽若低于 ~133MB/s，单 chunk 传输就可能超时
真正容易被忽略的是：同一个应用里混用不同 chunkSizeBytes 的 bucket 实例，会导致 fs.files 里 chunkSize 值不一致，后续用 find() 查出来的文件，你没法确定该用哪个 bucket 去读——元数据和 bucket 配置必须严格对齐。
