需手动注册office mime类型并用libreoffice异步转pdf预览，禁用http.servefile直接返回.docx等文件，设置超时与资源限制防雪崩，校验路径防越权。
用 net/http 提供静态文件服务前先确认 MIME 类型是否正确
浏览器能否正常预览 PDF 或 Office 文件，第一关不是后端逻辑，而是响应头里的 Content-Type。Golang 的 http.ServeFile 和 http.FileServer 会依赖文件扩展名自动推断类型，但默认不识别 .docx、.xlsx 等现代 Office 格式，容易返回 text/plain 或空类型，导致下载而非预览。
实操建议：
- 手动注册缺失的 MIME 类型，例如在服务启动前调用
mime.AddExtensionType(".docx", "application/vnd.openxmlformats-officedocument.wordprocessingml.document") - 避免直接用
http.ServeFile返回 Office 文件；改用http.ServeContent，自己设置Content-Type和Content-Disposition: inline - PDF 文件通常没问题（
.pdf→application/pdf），但若文件名无后缀或被重命名，仍会出错
PDF 文件可直接由浏览器渲染，但 Office 文件必须转成 PDF 或图片
目前没有任何主流浏览器支持原生渲染 .docx、.xlsx 或 .pptx —— 它们不是网页标准格式。所谓“在线预览”，本质是服务端转换 + 前端展示。Golang 本身不提供 Office 解析能力，必须借助外部工具链。
实操建议：
- Linux 服务器上优先用
libreoffice --headless --convert-to pdf命令行转换，稳定、开源、支持全格式 - 不要尝试用纯 Go 库（如
unidoc）处理复杂 Office 文档：授权贵、对公式/图表/分栏支持弱、易 panic - 转换后缓存 PDF 文件（按源文件哈希命名），避免重复转；注意清理临时文件和超时进程，
libreoffice残留进程会卡死后续请求
调用 libreoffice 时必须设好超时和资源限制
libreoffice --headless 启动慢、内存吃得多，且某些损坏文档会导致它卡住不退出，进而拖垮整个 HTTP handler。Golang 的 exec.Command 默认没有超时，也不限制 CPU/内存，线上环境极易雪崩。
实操建议：
- 用
exec.CommandContext包裹，传入带超时的context.Context（例如 30 秒） - 加上
syscall.Setrlimit（Linux）限制子进程内存，防止一个大 PPT 吃光服务器内存 - 捕获
exit status 77（libreoffice 转换失败常见码）、signal: killed（OOM Killer 干掉的提示），返回明确错误而不是 500 - 不要在 HTTP handler 里同步等转换完成；高并发下应走异步队列（如简单 channel + worker），但小流量可同步做
前端用 <iframe></iframe> 加载 PDF 是最简方案，但要注意路径和跨域
生成 PDF 后，前端只需一个 <iframe src="/preview/xxx.pdf"></iframe> 即可显示。看似简单，但几个细节常被忽略：
实操建议：
- 确保 PDF URL 路径可被静态服务访问，且不经过需登录校验的中间件（否则 iframe 会弹 401）
- 如果预览接口和主站不同域，需后端响应加
Access-Control-Allow-Origin: *（仅限可信来源）或配置反向代理抹平域名 - 移动端 Safari 对 iframe 中 PDF 渲染有 bug（空白或缩放异常），可 fallback 到
<embed></embed>或引导用户下载 - 别把 PDF 文件路径拼在 URL 里直接暴露（如
/preview?file=../../etc/passwd），务必校验路径是否在允许目录内，用filepath.Clean+strings.HasPrefix做白名单检查
真正麻烦的从来不是“怎么调 libreoffice”，而是怎么让它不卡、不崩、不越权、不泄露——这些边界条件没压住，功能上线第一天就会在半夜报警。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
