直接写入超16mb文档会报payload document size is larger than maximum of 16mb或bsonmaximumsizeexceededexception错误；gridfs因fs.chunks和fs.files结构固定、字段不可索引且不支持$match/$sort/$group等聚合操作，故无法直接聚合查询内容。
直接写入大文档会报什么错
遇到 Payload document size is larger than maximum of 16MB 或 BsonMaximumSizeExceededException，说明你正试图插入或更新一个超限文档——这不是配置问题，也不是驱动 bug，而是 MongoDB 底层 BSON 协议的硬性拦截。它会在网络层就拒绝请求，根本不会进入存储引擎。
GridFS 存完大 JSON 后，为什么聚合查不了内容
GridFS 把文件切进 fs.chunks（二进制块）和 fs.files（元信息），这两个集合结构固定、字段不可索引：
-
fs.files.filename是字符串，但默认没建索引；uploadDate是ISODate，也不带业务语义 -
fs.chunks.data是BinData类型，聚合管道里连$match都不支持，更别说$group或$sort - 对
fs.chunks执行聚合会直接报错：errmsg: "cannot use $group in fs.chunks"—— 这是设计限制，不是权限或语法问题
真正能跑聚合的方案：GridFS + 元数据集合
核心是把“存”和“查”拆开：用 GridFS 存原始大 JSON，用独立集合存可索引、可聚合的业务字段，并通过 file_id 关联。
- 元数据文档里必须含
file_id: ObjectId("...")，且值要与fs.files._id完全一致，否则$lookup关联失败 - 只存摘要字段：比如
errorCount、durationMs、deviceId、timestamp，别把整个 JSON 结构复制进去 - 所有需查询/排序的字段都要单独建索引，例如：
db.large_docs_meta.createIndex({ deviceId: 1, timestamp: -1 }) - 上传时必须同步写元数据，不能靠事后补 —— 应用层要保证原子性（可用事务包裹 GridFS 写入 + 元数据插入）
分表（子文档拆分）适合哪些场景
拆成多个子文档不是万能解，只适用于逻辑上可分割、且查询模式固定的场景：
- 子文档彼此独立（如用户评论列表），无跨文档统计需求
- 查询总是先取主文档，再按 ID 批量拉子文档（比如
db.comments.find({ postId: "abc" })） - 子文档数量可控（几百条以内），否则应用层合并成本高
- 更新单条子文档时，能接受统计字段（如
totalCommentCount）不同步 —— 或者自己加双写逻辑
如果业务需要按时间范围对“十年日志”统一排序、分页跳转到第 10001 条，或者要实时计算 errorRate = errorCount / totalCount，那拆文档反而让问题更重：MongoDB 不支持跨文档数组展开后全局排序，也做不到原子性更新主从统计。
