GridFS不提供文件级压缩，需应用层手动压缩；删除后空间不释放是WiredTiger设计所致，唯一彻底回收方式是导出→清空→重建。
GridFS 本身不提供文件级压缩功能，所谓“压缩大文件”，实际是指两件事：一是减少上传前的文件体积（应用层压缩），二是回收删除后残留的磁盘空间（存储层空间回收）。两者完全无关，但常被混为一谈。
上传前用 gzip / zlib 压缩原始文件再存入 GridFS
GridFS 不会对内容自动压缩，它只是把输入流原样切块存进 fs.chunks。想减小存储体积，必须在写入前手动压缩。
- 对文本类文件（日志、JSON、XML）效果显著；对已压缩格式（JPEG、MP4、ZIP）几乎无效，甚至可能略微增大体积
- Python 示例：
fs.put(gzip.compress(file_bytes), filename="report.json.gz", metadata={"original_name": "report.json"}) - Java 中可用
java.util.zip.GZIPOutputStream包裹InputStream后传给GridFSInputFile - 务必在
metadata或文件名中记录原始格式，否则读取时无法正确解压
删除大量文件后，compact 命令无法释放磁盘空间
执行 db.runCommand({compact: "fs.chunks"}) 后 du -sh 显示的磁盘占用几乎不变——这不是命令没生效，而是 WiredTiger 的设计使然。
-
compact只重排内部页、合并空闲 slot，不触发文件系统级空间归还 -
fs.chunks文档极小（默认 256KB/chunk），大量删除后留下的是细碎空洞，compact效率远低于业务集合 - 该命令要求集合独占锁，期间所有读写阻塞，线上环境慎用
真正回收磁盘空间必须走导出→清空→重建流程
WiredTiger 引擎下，唯一能降低 .wt 文件物理大小的方式是彻底重建数据文件。
- 导出存活数据：
mongodump --gzip --db your_db --collection fs.files --collection fs.chunks -o /backup/ - 停 mongod，手动删除数据目录下所有
fs.*.wt文件（⚠️仅限维护窗口，确认无其他进程访问） - 重启 mongod，再用
mongorestore --gzip /backup/导入——此时生成全新、无碎片的.wt文件 - 若无法停服，可尝试
db.adminCommand({compactServer: true})+ 文件系统级fstrim（仅限 SSD + XFS/ext4 启用discard挂载选项）
最易被忽略的一点：GridFS 删除后空间不释放，不是运维疏忽，而是 WiredTiger 为保障写入吞吐和崩溃恢复能力做的主动取舍。日常应盯住 db.fs.chunks.stats().storageSize / db.fs.chunks.stats().size 比值，一旦超过 2.0，说明碎片已严重，该安排重建了。
