最直接的租户隔离方式是为每个租户分配独立bucketName，通过物理分离files和chunks集合实现硬隔离，避免元数据过滤风险，并需配合集合级权限控制、规范化命名、动态实例化及租户删除时的集合清理。
每个租户用独立 bucketName 是最直接的隔离方式
GridFS 本身不提供“租户”概念，但通过显式指定 bucketName 参数，就能让不同租户的数据物理隔离：各自写入不同的 files 和 chunks 集合。比如租户 tenant-a 用 bucketName: 'tenant_a_files'，租户 tenant-b 用 bucketName: 'tenant_b_files'，两者在 MongoDB 中完全无交集。
这样做避免了元数据字段（如 metadata.tenantId）过滤带来的风险——万一查询漏加条件、索引没建好、或有人绕过业务层直连数据库，就可能跨租户读取。而集合级隔离是硬隔离，MongoDB 层面天然不互通。
-
bucketName必须合法：只能含字母、数字、下划线和短横线，且不能以数字开头 - 建议统一前缀（如
tenant_），便于运维识别和权限控制 - 创建
GridFSBucket实例时必须传入该名称，否则默认使用fs，极易引发混淆
上传/下载时动态构造 GridFSBucket 实例，别复用全局单例
常见错误是初始化一个全局 bucket 实例，在所有请求中重复使用。一旦多租户共用同一个实例，bucketName 就被固定死了，无法切换。
正确做法是在每次请求上下文中，根据当前租户标识（如从 JWT 解析出的 tenantId）动态生成 GridFSBucket：
const tenantId = 'acme-inc'; // 来自请求上下文
const bucket = new mongodb.GridFSBucket(db, {
bucketName: `tenant_${tenantId.replace(/[^a-z0-9_]/g, '_')}`
});
- 务必对
tenantId做白名单校验或规范化处理，防止注入非法字符导致集合名无效 - 不要缓存这个
bucket实例到模块顶层；它只应在本次请求生命周期内有效 - 如果高频创建实例影响性能，可考虑用 Map 缓存已构造过的
bucket（key 为规范化后的bucketName），但需注意内存泄漏风险
权限控制必须落到集合级别，不能只靠应用层拦截
即使每个租户有独立 bucketName，若数据库用户拥有 dbAdmin 或通配符权限（如 readWriteAnyDatabase），仍可能直接查询任意 tenant_xxx_files 集合。真正的隔离需要 MongoDB 角色权限配合。
- 为每个租户创建专用数据库用户，仅授予其对应
bucketName下两个集合的读写权限：tenant_xxx_files.files和tenant_xxx_files.chunks - 避免使用
readWrite数据库角色，它允许访问该库下所有集合 - 若租户数极多，可用 MongoDB 6.0+ 的
resource pattern动态匹配（如{ resource: { db: "myapp", collection: "tenant_.*_files\.files" } }），但需确认驱动和部署版本支持
删除租户时，要连带删掉整个 GridFS 桶的集合
租户注销或停用时，仅删除业务表中的租户记录是不够的。对应 bucketName 下的 files 和 chunks 集合仍残留大量二进制数据，持续占用磁盘空间。
必须显式执行集合清理：
// 删除 tenant_acme_files.files 和 tenant_acme_files.chunks 两个集合
await db.collection('tenant_acme_files.files').drop();
await db.collection('tenant_acme_files.chunks').drop();
- 不能依赖
bucket.drop()—— 它只清空内容，不删集合，后续上传会自动重建，但集合元数据（如 TTL 索引）可能残留异常 - 生产环境执行前务必确认
bucketName与租户 ID 严格匹配，拼错会导致误删其他租户数据 - 建议在事务外单独做删除，并加入日志和告警，这类操作不可逆
真正麻烦的不是怎么分桶，而是租户生命周期管理——从创建、使用到彻底清理，每一步都得和集合名、权限、监控对齐，漏掉任何一环，隔离就形同虚设。
