gridfs本身不提供高可用能力，必须依赖mongodb副本集实现故障自动转移；它不支持目录树、随机写、覆盖语义或权限控制，这些需应用层补足。
GridFS 本身不提供高可用能力，必须依赖 MongoDB 副本集（replica set）实现故障自动转移；它也不支持目录树、随机写、覆盖语义或权限控制——这些全得由应用层补足，否则上线即踩坑。
为什么 GridFS 必须跑在副本集上，不能单节点或分片集群直接用
GridFS 的 fs.files 和 fs.chunks 是普通集合，没有特殊容错机制。单节点宕机 = 整个网盘不可写、不可读；分片集群虽能扩展吞吐，但 GridFS 不支持跨分片事务，上传/删除/重命名等操作一旦涉及多个分片，极易出现元数据与文件块不一致。
- 副本集是唯一被 MongoDB 官方明确支持用于 GridFS 高可用的部署模式：主节点挂了，从节点 10–30 秒内自动选举新主，
gridFSBucket客户端会自动重连，业务无感 - docker-compose 示例中三个容器共用
--replSet rs0，初始化后必须手动执行rs.initiate()和rs.add()，否则只是三个孤立 mongod，不构成副本集 - 生产环境务必禁用
bind_ip_all，改用具体内网 IP；否则副本集心跳和客户端连接可能因绑定混乱失败
如何安全上传大文件并防止元数据残留
GridFS 没有“覆盖上传”原子操作：uploadFromStream(filename) 传同名文件，只会新增 fs.files 记录，旧 fs.chunks 文档永久滞留，磁盘越用越多，且查询时可能返回错误版本。
- 企业级必须放弃
filename作为业务主键，改用业务唯一 ID（如user_id:file_id）存入metadata字段，并在fs.files上建唯一索引：db.fs.files.createIndex({ "metadata.fileId": 1 }, { unique: true }) - 上传前查重 + 删除旧记录必须在一个事务中完成（MongoDB 4.0+ 副本集支持），Node.js 中需用
session.withTransaction()包裹三步：find→deleteMany({ files_id: oldId })onfs.chunks→uploadFromStream - 别信驱动自动清理：Java Driver 的
GridFSBucket.delete()只删fs.files，fs.chunks得手动配deleteMany清理，漏掉就成垃圾
目录结构怎么建才不拖慢查询、不引发循环引用
用 filename: "photos/2024/vacation.jpg" 模拟路径是典型反模式：正则查询 { filename: { $regex: "^photos/2024/" } } 无法走索引，10 万文件就卡死；重命名整个目录得批量更新，没事务兜底就丢数据。
- 新建独立集合
files_meta，每条文档代表一个节点（文件或目录），关键字段：name（不含路径）、parent_id（指向父节点_id）、type（"file" / "directory"）、file_id（仅文件有，关联fs.files._id） - 查某目录下所有子项？简单一条：
db.files_meta.find({ parent_id: ObjectId("...") })，加索引{ parent_id: 1 }即可毫秒响应 - 创建新目录时，必须递归检查
parent_id链是否形成闭环（比如 A→B→C→A），否则后续$graphLookup查后代会无限循环；建议在插入前用聚合管道预检
下载性能差、内存溢出、并发卡顿的真实原因和解法
GridFS 下载本质是顺序查 fs.chunks 并拼接二进制流。默认 chunkSize=255KB，小文件（
- 小文件（BinData 直接存进普通集合文档，避免 GridFS 开销；GridFS 只留给 >16MB 或需范围读取（如视频跳播）的场景
- 下载必须用流式接口（
openDownloadStreamById），绝不能toArray()拉全量 chunks 到内存；Node.js 中配合pipe()直接吐给 HTTP 响应体 - 高并发下载时，
fs.chunks的{ files_id: 1, n: 1 }复合索引必须存在且健康，缺失会导致全表扫描；定期用db.fs.chunks.getIndexes()核查
最易被忽略的是：GridFS 元数据和业务元数据（如目录树、权限、回收站）永远不在同一张表里，任何跨集合操作（移动、复制、回收）都得自己实现幂等性、状态校验和异步补偿，别指望 MongoDB 自动兜底。
