公司用 LibreOffice 做 Office 文件的在线预览——把 Word/Excel/PPT 转成 PDF，前端用 PDF.js 展示。平时用着没问题，但每个月财务批量导出报表的时候，几十个人同时点预览。LibreOffice 进程 fork 了十几个，其中一个转一个 50MB 的 Excel 文件卡了 10 分钟。这个卡住的进程占着 CPU 不干活，后面排队的请求全堵住了。运维 ssh 上去 kill -9 才恢复。 LibreOffice 的 --headless 模式是为单次使用设计的，不是为高并发设计的。今天聊聊怎么用 Docker 容器隔离每个转换任务、超时强杀、再加一个队列缓冲——让文件预览服务从"一卡俱卡"变成"各管各的"。 问题：共享的 LibreOffice 进程没有隔离 最简单的预览方案是在服务器上直接调 LibreOffice： soffice --headless --convert-to pdf input.docx 第一次调会 fork 一个 LibreOffice 后台进程。后续调用如果这个进程还在，就复用。如果这个进程卡死了——比如遇到了一....

去年一个做在线文档平台的哥们半夜被运维叫起来。服务器 CPU 打到 100%，磁盘疯狂读写，查了半天发现有人在后台跑挖矿脚本。溯源之后找到入口——一个用户上传的 .docm 文件，里面有段恶意 VBA 宏。系统调用 Office 转 PDF 的时候，宏被执行了，服务端直接中招。 这事儿比 SQL 注入还吓人。注入你得找到注入点，宏病毒你只要把文件上传上去，别人帮你打开，你就进去了。 文件预览几乎是所有企业应用的标配——合同管理要预览 PDF、OA 系统要预览 Word、网盘要预览 Excel。但很少有人意识到，每次把用户上传的 Office 文件扔进转换引擎，都等于在服务器上双击了一个陌生人发给你的附件。 今天聊聊怎么用进程隔离的思路，把这个风险降到最低。 宏病毒是怎么在服务端生效的 很多人觉得"我服务端又没有 Office 软件，哪里来的宏？" 但实际上，现在主流的文件预览方案底层都绕不开文档转换引擎。LibreOffice、OnlyOffice、Apache POI——它们做的事情就是把 docx / xlsx / pptx 转成 PDF 或者 HTML，然后前端渲染。而这些引....