MongoDB GridFS 不支持内置用户级存储配额，需通过应用层校验+独立bucket+聚合统计length总和实现；须避免误用length字段、确保删除触发chunk清理，并结合collStats与日志交叉核对真实用量。
MongoDB GridFS 本身不支持用户级存储配额控制，必须靠应用层或数据库权限+监控组合实现。
GridFS 没有内置配额机制
GridFS 是一个客户端驱动的文件分块协议，MongoDB 服务端不识别“用户上传了多少文件”或“占用了多少空间”。fs.files 和 fs.chunks 就是普通集合，服务端只做文档读写，不统计、不限制、不拦截。你无法通过 db.createRole 或 collMod 设置“该用户最多存 500MB”。
用 collection-level 权限 + 应用层校验模拟配额
这是目前最可行的落地方式，核心思路是：让每个用户独占一个 GridFS bucket（而非共用默认 fs），再在应用写入前查总量、做拦截。
- 创建独立 bucket 名，比如按用户 ID 命名：
fs_user_12345，对应集合为fs_user_12345.files和fs_user_12345.chunks - 给该用户分配仅对这两个集合的
insert/find权限，禁止跨 bucket 操作 - 每次调用
uploadFromStream前，先执行聚合查询：db["fs_user_12345.files"].aggregate([ { $group: { _id: null, total: { $sum: "$length" } } } ]) - 若
total超过阈值（如 2GB），直接拒绝上传，不走 GridFS 流程
避免误用：不要依赖 fs.files.length 字段做配额判断
fs.files.length 是单个文件大小，不是用户总用量；而且它可能被绕过——比如用户上传 100 个 1MB 文件，length 每个都是 1048576，但总用量已达 100MB。真正要算的是所有 fs_xxx.files 文档的 length 字段之和。
更隐蔽的坑是：如果用户删了文件但没清空 fs_xxx.chunks（比如只删 files 文档），磁盘空间不会释放。必须确保删除走的是 deleteId 或 deleteMany 并触发 chunk 清理（现代驱动通常自动处理，但旧版 Node.js 驱动 gridfs-stream 不保证）。
监控与兜底：定期扫描实际磁盘占用
因为 MongoDB 的 WiredTiger 引擎存在压缩、预分配、journal 等因素，length 总和 ≠ 实际磁盘占用。生产环境建议：
- 每天用
db.runCommand({ dbStats: 1 })或db["fs_user_abc"].stats()抽样检查 bucket 大小 - 对
fs_xxx.chunks集合加 TTL 索引（需配合业务逻辑标记“待清理”状态），防止孤儿 chunk 积压 - 在备份/归档流程中，把超配额用户的文件迁出并通知管理员人工介入
配额真正的难点不在“怎么设”，而在“怎么准”和“怎么清”——length 可骗，dataSize 可压缩，只有定期 collStats + 应用层日志交叉核对，才能逼近真实用量。
