Compass 不直接渲染 GridFS 文件内容，但可查看 fs.files 和 fs.chunks 集合的原始文档结构以排查文件存在性、元数据正确性及分块完整性；需手动定位对应集合，重点核对 _id、filename、length、chunkSize、uploadDate 及 fs.chunks 中的 n 字段连续性，并确认连接实例与数据库名一致。
Compass 本身不直接渲染 GridFS 文件内容，但能让你看到 fs.files 和 fs.chunks 集合里的原始文档结构——这是排查文件是否存在、元数据是否正确、分块是否完整的关键入口。
在 Compass 中定位 GridFS 集合
GridFS 默认使用 fs 作为存储桶前缀，对应两个集合：fs.files 存元数据，fs.chunks 存二进制分块。Compass 不会自动“识别”它们为“文件”，所以你得手动找：
- 左侧数据库列表中展开目标数据库（比如
test） - 向下滚动，找到名为
fs.files和fs.chunks的集合（注意不是fs单个集合） - 如果用了自定义存储桶名（如
photos），则对应集合是photos.files和photos.chunks，需按实际名称查找
查看 fs.files 文档时重点关注什么
这个集合每条文档代表一个上传的文件，字段少但信息关键：
-
_id：必须和你在代码里传给openDownloadStream()的参数一致，类型通常是ObjectId或string（取决于驱动） -
filename：原始文件名，可用来人工核对 -
length：总字节数，和本地文件大小对比可快速判断是否上传完整 -
chunkSize：默认255 * 1024（255 KiB），若你代码里显式设了chunkSizeBytes，这里会体现 -
uploadDate：ISODate 时间，确认是否是最新上传的那批
为什么打开 fs.chunks 看不到明文内容
fs.chunks 里的 data 字段是 BinData 类型，Compass 在 JSON 视图里只显示类似 {"$binary": {"base64": "...", "subType": "00"}} 的摘要，不会解码或渲染二进制内容：
- 不要试图从这里“读取”文件内容——它本来就不该被人工阅读
- 真正要验证分块完整性，看
n字段：它表示该 chunk 的序号，应从0开始连续递增；最后一块的n值应等于Math.floor((length - 1) / chunkSize) - 如果发现
n缺失、跳号或重复，说明上传中途失败或驱动写入异常
无法下载或流式读取？先查这三个地方
当代码调用 openDownloadStream() 报 FileNotFoundException，别急着改代码，先在 Compass 里交叉验证：
- 确认
fs.files中存在对应_id的文档（注意 ObjectId 格式是否带引号、大小写） - 检查该文档的
filename和你代码里uploadFromStream()用的名字是否完全一致（含空格、大小写、扩展名） - 确认数据库连接的是**同一个** MongoDB 实例和数据库名——Compass 左上角显示的连接字符串和你的应用配置必须一致，常见坑是本地连
localhost:27017，而应用连的是 Docker 容器或远程地址
GridFS 的调试本质是“查证三件事”：文件元数据是否存在、分块数量是否匹配、连接上下文是否一致。Compass 不提供一键预览，但它给出的每一条 fs.files 文档和每一个 fs.chunks.n 值，都是不可绕过的事实依据。
