企业官网建设流程全解析

kkFileView JDK8/JDK11 版本选型：国产化部署的三问实用指南

【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView

给 kkFileView 上线之前，第一个问题通常是：JDK 兼容性选 JDK8 还是 JDK11？现在项目已经在跑的 JDK21 又该怎么处理？kkFileView 是一个基于 Spring-Boot 的通用文件在线预览服务，把 Office、PDF、CAD 这些文件转成浏览器能直接看的格式。这篇文章从仓库里的真实配置和三个自测问题切入，读完你能拿到一套能直接套用的国产化 JDK 版本选型依据。

🔎 先看当前仓库实际用的版本

答案写在 pom.xml 里，就两行：

<java.version>21</java.version> <maven.compiler.source>${java.version}</maven.compiler.source>

意思是：现在官方版本（5.0.0，Spring Boot 3.5.6）基于 JDK 21 编译运行，而 Spring Boot 3.x 本身就要求 JDK 17 起步。所以谈"JDK8/JDK11"时，本质不是改一行配置，而是选 kkFileView 的哪个发布版本——直接拉当前代码，只能在较新的 JDK 上跑；环境锁死在 JDK8 或 JDK11 时，就得回到支持它们的旧版本线。

🧭 三问定选型：kkFileView 该配哪个 JDK

选型前过一遍这三个问题，每个问题对应一个版本：

1. 环境里其他系统用的是哪个 JDK？

如果公司基线统一了 JDK8 或 JDK11（国产化项目里很常见），别为了 kkFileView 单独升级，直接挑与它匹配的 kkFileView 发布版就行。

2. 服务器硬件规模多大？

内存吃紧（比如单机 4GB 以下）、预览频率不高的场景，JDK8 基础占用最省；资源宽裕、并发量大，JDK11 或 JDK21 的 GC 改进会更有余量。

3. 是老系统改造，还是全新项目？

老系统改造求稳，用环境里已经验证过的那个 JDK；全新项目建议直接跟官方现行版本走（JDK21），免得后面再折腾一次升级。

⚖️ 三个版本的定性差异

没有放之四海皆准的绝对数字（各环境实测都不一样），社区里通行的定性结论大致如下：

补两句：预览效果本身有没有差别，更多取决于 LibreOffice 组件和字体，而不是 JDK；启动和内存数据请以你自己环境的实测为准。

🛠️ 国产化环境部署要点

不管最终选哪个 JDK，部署时有三件事要确认：

• 缓存类型：application.properties 里有专门开关。单机用默认值即可，集群切 Redis，要磁盘持久化选 RocksDB：

cache.type = ${KK_CACHE_TYPE:jdk}

• 字体：仓库自带字体目录（docker/kkfileview-base/fonts/），在国产操作系统上部署时补全中文字体，生成的 PDF 才不会中文乱码。
• 跨平台：Windows、Linux 都支持；Linux 下注意 LibreOffice 安装路径（office.home）和目录大小写。

📋 三个高频问题

环境锁 JDK8，预览效果会有差别吗？

基本没有。转换效果更依赖 Office 组件和字体，只要 JDK 大版本与所用发布版匹配，效果一致。

一台机器能同时装两套 JDK，分别跑不同版本吗？

可以。启动时指到对应的 java 路径，端口错开（默认 8012），新旧版本并行灰度就是这么干的。

从 JDK11 直接升到 JDK21，改动量大吗？

没改过代码的话，直接拿当前官方版部署即可，它就是按 JDK21 开发的；改过代码则要先把 JDK 升到测试环境，对常用文件类型做一轮回归，这正是 Spring-Boot 项目 JDK 升级的标准姿势。

一句话按场景收口：老系统已经在 JDK8 上，就选匹配的 kkFileView 旧版；新机器求平衡，选 JDK11；资源充足的全新部署，跟官方现行版本走 JDK21。日后若升级 JDK，记得重新核对字体目录和一批真实文件的转换效果——这就是升级路径上最容易踩坑的地方。

【免费下载链接】kkFileViewUniversal File Online Preview Project based on Spring-Boot项目地址: https://gitcode.com/GitHub_Trending/kk/kkFileView