Node.js读取MongoDB图片数据“乱码”本质不是编码问题，而是将二进制Buffer误作文本处理：直接toString()或console.log导致Latin-1隐式转换、字节丢失；正确做法是用GridFSBucket.openDownloadStreamByName获取流，并设Content-Type后管道输出，严禁手动查chunks或toArray。
Node.js 读取 MongoDB 图片数据变乱码，本质不是编码问题
直接说结论：这不是 UTF-8 或 GBK 编码设置错误导致的乱码，而是把二进制图片数据（Buffer）当成了文本字符串去 console.log 或 res.send。MongoDB 存的是原始字节流，不是可读文本——你看到的“乱码”，其实是终端或浏览器强行用文本方式渲染二进制内容的结果。
GridFS 存图后用 findOne 直接取 Buffer 字段会出错
常见错误写法：collection.findOne({ filename: "avatar.jpg" }) 然后对返回对象里的 data 字段直接 toString() 或 JSON.stringify()。这会导致：
-
Buffer被隐式转成 Latin-1 编码字符串，高位字节丢失，图片损坏 - 如果字段是 GridFS 的
chunks集合里某条文档的data字段，它只是整张图的一小块，单独处理毫无意义 - 没走 GridFS 的读取流程（
openDownloadStream），根本拿不到完整、顺序正确的二进制流
正确读取 GridFS 图片必须用 openDownloadStream
GridFS 不是普通集合，它依赖文件分块 + 元数据两套集合协同工作。要读图，必须用官方驱动提供的流式接口：
示例（MongoDB Node.js Driver v6+）：
const { GridFSBucket } = require('mongodb');
const bucket = new GridFSBucket(db, { bucketName: 'images' });
// 正确：获取下载流
const downloadStream = bucket.openDownloadStreamByName('avatar.jpg');
// 正确：管道输出到响应（Express）
res.setHeader('Content-Type', 'image/jpeg');
downloadStream.pipe(res);
// 错误：不要这样做
// const fileDoc = await bucket.find({ filename: 'avatar.jpg' }).toArray();
// console.log(fileDoc[0].data.toString()); // ❌ 损坏且不完整
关键点：
-
openDownloadStreamByName自动合并所有chunks并按顺序拼接，返回标准ReadableStream - 务必设对
Content-Type，否则浏览器可能尝试用文本方式解析二进制流 - 不要手动调用
toArray()或findOne()去查fs.files或fs.chunks集合——那是底层实现，不该直用
本地调试时别用 console.log 打印图片 Buffer
开发中常犯的低级错误：为了“看一眼”图片内容，对 Buffer 调用 console.log(buf)。终端显示的 <buffer ff d8 ...></buffer> 是调试表示，不是乱码；但如果你看到一堆问号、方块或 Unicode 替换符（），说明你已经把它转成了字符串。
安全调试方式：
- 检查长度：
console.log('size:', buf.length) - 检查前几个字节（判断格式）：
console.log(buf.subarray(0, 4))—— JPEG 是[255, 216, 255, ...] - 写入文件再用看图软件打开：
fs.writeFileSync('debug.jpg', buf)
真正容易被忽略的是：即使你用了 openDownloadStream，如果后续中间件（比如 Express 的 compression）试图压缩二进制流，也可能破坏数据。遇到图片加载一半或花屏，先关掉所有非必要中间件排查。
