bsondump是MongoDB安装包里自带的一个命令行小工具，专门用来把BSON格式的二进制文件转换成JSON格式输出。很多同学在做数据备份恢复时用过mongodump，它导出的每个collection都会生成一个以.bson结尾的文件。如果直接用文本编辑器打开这个文件，看到的基本是一堆乱码加部分可读字符串，因为BSON是一种二进制序列化格式，并不是纯文本。这时候bsondump就派上用场了，它能帮你快速把文件内容还原成可读的JSON，方便检查备份数据是否完整、排查恢复失败的原因。
一、bsondump的基本语法和安装位置
bsondump随MongoDB服务端一起安装，不需要单独下载。在Linux环境下，它通常位于/usr/bin/bsondump目录；Windows环境下则在MongoDB安装目录的bin文件夹中，例如C:\Program Files\MongoDB\Server\bin\bsondump.exe。使用前建议先确认该目录已经加入系统PATH环境变量，否则需要写全路径执行。
它最基本的语法非常简单，后面直接跟BSON文件路径即可：
# 查看单个BSON文件内容 bsondump /data/backup/mydb/users.bson # 如果没配置环境变量，需要写完整路径 "C:\Program Files\MongoDB\Server\bin\bsondump.exe" D:\backup\users.bson
执行后，终端会逐行输出文件中的每一条文档，每条文档占一行JSON。输出结束后还会在标准错误流中打印类似"1 objects found"的统计信息，告诉你文件里一共有多少个对象。
二、常用参数详解
bsondump的参数不多，但每个都值得掌握。先看完整参数列表：
bsondump --help 选项: --quiet 隐藏统计信息输出 --type=<type> 输出格式: json (默认) 或 debug --pretty 输出格式化的多行JSON（MongoDB 4.2+支持） --verbose, -v 提高日志详细程度 --version 显示版本号 --help 显示帮助
其中--type是最值得关注的参数。默认值是json，输出标准JSON文本；如果指定--type=debug，则输出调试格式，会额外显示每个字段的BSON类型编号、字段长度等底层信息，非常适合用来分析文件损坏或字段类型异常的问题。debug格式的输出长这样：
bsondump --type=debug /data/backup/mydb/users.bson
输出中会包含类似{ "_id" : 1, "size" : 30, "type" : 7 }这样的行，其中type为7表示ObjectId类型，size表示该元素占用的字节数。通过这些信息可以判断BSON文件的内部结构是否符合预期。
--quiet参数用于关闭末尾的对象统计输出，在把结果通过管道交给其他工具处理时很有用。比如想把输出直接保存为JSON文件或交给jq做过滤：
# 转储为json文件并统计文档数量 bsondump --quiet /data/backup/mydb/users.bson > users.json wc -l users.json # 配合jq过滤年龄大于30的文档 bsondump --quiet users.bson | jq 'select(.age > 30)'
--pretty参数从MongoDB 4.2开始提供，作用是让输出变成带缩进的多行JSON，可读性更好，不过文件体积也会明显增大，处理大文件时要注意磁盘空间。另外提一句，bsondump不支持gzip压缩文件，如果备份时用了--gzip选项生成的是.bson.gz文件，需要先手动解压再交给bsondump处理。
三、bsondump与mongoexport、mongorestore的区别
初学者容易把这几个工具搞混，这里做一个对比说明。mongoexport是从运行中的MongoDB实例导出数据为JSON或CSV，操作对象是数据库服务；而bsondump的操作对象是磁盘上的BSON文件，不需要MongoDB实例在运行，即使数据库挂了也能用，这正是它在故障排查中价值最大的地方。
mongorestore则负责把BSON文件恢复回数据库，它中间也会解析BSON文件。如果你只想确认备份文件内容是否正确、是否包含目标数据，先用bsondump看一眼比直接mongorestore导入要快得多，也避免了误操作覆盖线上数据的风险。
| 工具 | 操作对象 | 是否需要数据库运行 | 典型用途 |
|---|---|---|---|
| bsondump | BSON文件 | 否 | 查看、校验备份文件 |
| mongoexport | 数据库实例 | 是 | 导出JSON/CSV |
| mongorestore | BSON文件 | 是 | 恢复数据到数据库 |
还有一个细节：bsondump只能读取，不能写入，它不会修改原始BSON文件，因此可以放心在生产备份目录上直接执行，不用担心破坏备份。此外，当BSON文件损坏时，bsondump会解析到出错位置并报错停止，根据报错信息中的偏移量，你还能大致判断文件损坏在哪一段，这对评估备份可用性很有帮助。
四、实战场景演示
假设一次mongodump备份完成后，运维同学反馈恢复时某个collection报错，提示"corrupt BSON document"。排查思路是先定位到对应的BSON文件，用bsondump逐段检查：
# 1. 查看文件能正常解析多少条 bsondump --quiet /backup/mydb/orders.bson | wc -l # 2. 如果中途报错，记录正常输出的行数， # 再结合debug模式查看出错位置的内部结构 bsondump --type=debug /backup/mydb/orders.bson > debug.txt 2>&1 # 3. 如果大部分数据完好，可以先用输出正常的部分做恢复 bsondump --quiet /backup/mydb/orders.bson > orders_part.json 2>/dev/null
第一个命令统计能成功解析的文档数量，与mongodump日志中的记录数对比就能知道损坏程度。第三条命令里把标准错误重定向到/dev/null，这样即使解析中断，已成功转换的JSON仍然保留在文件里，损失降到最低。
再比如日常的数据抽查场景：想确认备份里某个用户的资料是否存在，不必恢复整个库，直接配合grep就能完成：
bsondump --quiet /backup/mydb/users.bson | grep '"name" : "张三"'
总的来说，bsondump虽然功能单一，但在备份校验、故障排查、数据抽查这些场景下非常顺手。它不依赖数据库服务、只读不写、输出可以直接接入jq等文本处理工具，是MongoDB运维工具箱里值得熟练掌握的基础命令。