mongofiles 仅适用于开发调试、CI/CD 脚本或临时运维任务，不支持并发上传、无流式进度反馈、不可嵌入应用；生产环境应使用驱动提供的 GridFSBucket API。
mongofiles 适合什么场景
直接用 mongofiles 管理 GridFS 文件，只适用于开发调试、CI/CD 脚本或临时运维任务——它不支持并发上传、不提供流式进度反馈、也不能在应用中嵌入调用。如果你需要在 Node.js 或 Python 服务里动态存取文件，应该用对应驱动的 GridFSBucket API，而不是依赖这个命令行工具。
基础命令格式和必填参数
mongofiles 的核心操作（put、get、list、delete）都必须显式指定数据库名和连接串，否则默认连 localhost:27017/test，极大概率报错 connection refused 或找不到文件。
- 必须加
--db <dbname>，例如--db myapp - 推荐加
--host <host>:<port>，例如--host mongodb-01:27017；若用副本集，得写--host rs0/mongodb-01:27017,mongodb-02:27017 - 如果启用了认证，必须加
--username、--password和--authenticationDatabase（通常是admin）
漏掉任一参数，mongofiles list 可能返回空，mongofiles put 可能静默失败或写进错误库。
文件名冲突与覆盖逻辑要特别小心
mongofiles put 永远不会覆盖已有文件，哪怕文件名、大小、内容完全一致——它只会插入一条新文档到 fs.files，并生成对应的新 fs.chunks 块。这意味着：
- 重复执行
mongofiles put logo.png会留下多个_id不同但filename相同的记录 -
mongofiles get logo.png默认只取最新插入的那一个（按uploadDate降序），但你无法从命令行判断到底取了哪条 - 想精确控制，必须用
mongofiles delete --id <objectid>先删，再put；或者改用mongoshell 查db.fs.files.find({filename: "logo.png"})手动确认
生产环境切勿依赖文件名做唯一标识，_id 才是唯一锚点，而 mongofiles 对 _id 的支持非常有限（仅 delete --id 和 get --id 可用）。
块大小和性能影响几乎不可控
mongofiles 固定使用 255KB 块大小（即 chunkSizeBytes: 261120），不提供任何参数修改。这在多数场景下够用，但如果你明确需要小块（如高频随机读取视频片段）或大块（如减少 chunk 文档数量以降低索引压力），它完全无能为力。
更关键的是：它无法设置自定义 metadata 字段，所有上传文件的 fs.files 文档里只有默认字段（filename、length、chunkSize、uploadDate、md5）。这意味着你没法通过 mongofiles 实现按业务标签（如 user_id、version）查询，只能靠应用层额外维护映射表。
