GridFS存储的Office文件无法直接预览，需确保完整写入、二进制流正确、LibreOffice转换配置合理、流式响应头设置正确、并发限制及缓存优化，并对不可渲染内容做前端提示。
GridFS 存储的 Office 文件无法直接预览？先确认文件是否完整写入
GridFS 本身不解析文件内容，只负责分块存储和拼合。如果 findOne 能查到文件元数据但流式读取时卡住、返回空或报 GridFSBucketReadStream is not readable，大概率是写入阶段就出问题了。
- 用
uploadFromStream写入时，确保传入的 stream 已触发end或close，否则files集合里可能没生成对应文档 - 检查
files集合中该文件的length是否与原始文件字节一致，chunkSize是否为默认261120（255KB）——非标准值可能导致下游解析器拒绝识别 - Office 文档（尤其是 .docx/.xlsx）对 ZIP 结构敏感，若上传前被 Node.js 的
fs.createReadStream错误地以文本模式打开（如加了encoding: 'utf8'），会破坏二进制头，后续所有转换服务都会返回“格式错误”
用 LibreOffice headless 模式转 PDF：必须绕过临时文件路径权限问题
直接调用 libreoffice --headless --convert-to pdf 是最轻量的转换方式，但 GridFS 流不能直接喂给命令行。常见错误是先 stream.pipe(fs.createWriteStream('/tmp/xxx.docx'))，再执行转换——这在容器或无写权限环境必然失败。
- 改用
child_process.spawn+stdin输入：LibreOffice 支持从 stdin 读取（需加--convert-to pdf:writer_pdf_Export --outdir /dev/stdout，注意不同版本参数略有差异） - 务必设置
env: { HOME: '/tmp' }，否则 LibreOffice 尝试写缓存到/root/.config会因权限拒绝崩溃，错误日志里只有Signal 6 (Aborted)这种模糊提示 - 转换后 PDF 流体积可能比原文件大 3–5 倍，别用
res.send()直接吐，要用res.writeHead(200, { 'Content-Type': 'application/pdf' })+pdfStream.pipe(res)流式响应，避免内存溢出
前端预览时 PDF.js 报 Unexpected server response (0) while retrieving PDF
这不是 PDF.js 的错，而是服务端流式响应没设对 HTTP 头。GridFS 读取流默认不带 Content-Length，而 PDF.js 在某些版本里会因缺少该头拒绝加载。
Office Open XML Automation Helper
下载
构建并调试跨Office自动化流程，实现Word、Excel、PowerPoint之间的内容迁移，使用Open XML、VBA、python-docx、openpyxl、py...
- 不要手动计算文件长度再塞进 header——GridFS 文件可能超 16MB，且分块存储导致
length字段只是逻辑长度，实际传输可能因压缩/编码有偏差 - 改用
res.writeHead(200, { 'Content-Type': 'application/pdf', 'Accept-Ranges': 'bytes' })，让浏览器走 Range 请求；PDF.js 会自动发起Range: bytes=0-1023探测，成功后才继续加载 - 如果后端用了 Nginx 反向代理，确认它没禁用
proxy_buffering off，否则会攒满整个 PDF 流才转发，导致前端超时
并发高时 LibreOffice 进程堆积，CPU 打满
LibreOffice 启动慢（单次约 800ms），且每个进程占 150MB+ 内存。不做限制的话，10 个并发请求就会 fork 出 10 个进程，很快耗尽资源。
- 用
p-limit包硬限并发数，例如const limit = pLimit(3)，把limit(() => convertStream(fileStream))包裹转换逻辑 - 别复用同一个 LibreOffice 进程（它不支持多路复用 stdin），但可以复用进程池：用
worker_threads启一个长期运行的 LibreOffice worker，主进程通过postMessage发送 buffer，worker 转完再发回 buffer —— 这能省掉 90% 启动开销 - 对已转换过的文件做简单哈希缓存（比如用
files._id+files.uploadDate拼成 key），避免重复转换。注意：Office 文档内容修改后uploadDate会变，但_id不变，所以不能只用_id
真正麻烦的是 Office 文档内嵌字体、OLE 对象、宏代码这些 LibreOffice 无法可靠渲染的部分——它们不会报错，只会静默降级，最终预览效果和原文档有偏差。这种 case 只能靠前端加提示：“部分内容可能无法准确显示”，而不是强行塞进转换流程里硬扛。
