kekingcn/kkFileView

如果你的应用需要在浏览器里展示用户上传的文档，并且团队愿意在应用旁运行一个 Java 转换服务，这个项目值得试；如果只需要看 PDF，或部署环境要求极简、无状态，就不合适。

解决什么问题

原来的流程是：用户上传一个 .docx、.dwg 或 .zip，网页要么直接给下载链接，要么提示安装本地软件。你希望的是上传后点一下就能在浏览器里看到内容。kkFileView 把这一步变成一次服务端转换：接收文件地址或上传的文件，调用转换器处理后返回浏览器能渲染的页面，用户拿到的是一条预览链接，而不是原文件下载。

有什么不同

核心是一个 Spring Boot 服务，通过 Jodconverter 调用 LibreOffice/OpenOffice，Redis 为可选项。Office 文档会被转换成 PDF 或图片，项目同时提供 REST API 和可扩展的预览接口。README 还列出了 PDF、ODF、CSV、xlsx、3D 模型等格式的前端解析，以及 CAD 转 SVG/TIF、压缩包浏览、加密文件预览等能力。好处很直接：一个服务覆盖多种文件，不用为每种格式分别接一个查看器。

代价是它本质上是一个 Java 边车服务，依赖并调用 OpenOffice/LibreOffice，转换超时、内存和磁盘占用都会成为你的运维问题。更新记录显示作者在持续处理这类问题：不可信 HTML 预览被放进不透明来源的 iframe，默认禁用内嵌 JavaScript，多个 SSRF、路径穿越和演示接口问题已在更新说明中修复 项目更新记录。这些是作者自述的修复，不是独立安全审计。3.0 版本还强制要求 JDK 21，Office 预览默认改为 PDF 模式，trust.host 的匹配规则也有调整，升级前必须重新核对配置。

谁值得试

适合：内部 OA、文档管理或内网门户，员工要在浏览器里打开合同、表格、图纸和压缩包，并且团队本来就在跑 JVM 服务。不适合：只用来分享 PDF 的静态站点或无服务器应用，额外的转换器和常驻进程都是负担。项目提供 Docker 镜像（含 ARM64），如果团队更习惯容器而不是手动安装 LibreOffice，可以走这条部署路线 部署说明。是否真的符合你的文档类型，可以先看官方演示 演示站。

使用条件与边界

当前版本强制要求 JDK 21 或更高。README 说 Linux 上会自动安装 Office/LibreOffice，macOS 需要手动安装，Windows 已集成。Redis 默认不需要，先读配置再决定是否引入。仓库元数据里没有声明许可证，如果要再分发或嵌入商业产品，需要先向维护者确认授权，而不是默认它是某个开源协议。

长期维护成本更值得关注。转换依赖外部办公套件，超时和线程池可配置；README 提到转换后的源文件默认会被删除以节省磁盘。trust.host 和危险文件上传限制决定服务会去抓取或接受什么，安全更新历史说明这些设置值得在每次升级时复查。office.preview.type 的默认值和 trust.host 的匹配方式都变过，升级不是无缝替换。

HotRepo 点评

HotRepo 目前只有 2026-10-28 这一个日榜观测：当天 14,809 stars，新增 4 个。单次快照不足以判断热度是在延续还是消退，2017 年的创建时间也不能说明当前维护质量。可以把它当作一个成熟的候选项目，但在面向不受信任的用户之前，先花时间核对许可证状态和主机信任、上传相关配置。