前段时间接手线上服务器的运维微调工作，部署新的Java业务包的时候一直启动失败，情急之下研究linux如何查看jdk版本，才发现服务器里的jdk环境和本地开发环境完全对不上，这也是项目报错的根本原因。很多人觉得查版本是基础操作，但实操的时候很容易忽略细节，导致查出来的信息不准，白白浪费大把的调试时间，我这次就是栽在了最基础的环境核查上。
最开始随便搜了个指令就敲，完全没考虑适配性。
当时随手输入java -version，终端确实跳出了一串版本数字，粗略扫了一眼以为环境没问题，就转头修改项目配置、调整参数，结果反复打包、上传、重启服务，流程走了四五遍，项目依旧启动异常，折腾了快半个钟头，越调越烦躁。后来才反应过来，这个简易指令查的只是系统当前临时生效的运行环境版本，不代表服务器实际完整安装的jdk版本，要是服务器并存了多个jdk安装包，这个结果就会出现偏差，根本没法作为环境适配的依据。
还有个很多新手都会踩的低级误区。
大部分人分不清java -version和javac -version的区别，我之前也傻傻把两个指令混着用，反复切换输入对比数据，完全没抓到核心。其实前者对应的是JRE运行环境的版本，只负责程序的运行加载，后者才是真正的JDK编译开发版本，后端项目部署、代码编译适配，真正需要核对的永远是javac的版本。很多线上Linux服务器为了精简空间，只会预装运行环境，不会装完整的开发工具包，这就会导致两个指令查询结果不一致，也是项目兼容报错的隐形原因。
真正能摸清全部版本的方法，就一个核心操作。
在Linux终端直接输入rpm -qa | grep jdk就行，这条指令会全盘扫描服务器系统内所有已安装的jdk相关安装包，不管是系统初始自带的老旧版本，还是后期手动编译、yum安装的新版本，都能完整罗列出来，版本号、安装包后缀、适配架构全部一目了然，不会出现遗漏、错判的情况，适配绝大多数CentOS系列的服务器，实操下来比简易指令靠谱太多。
不同Linux系统还要换对应的查询指令，不能一概而论。
如果是Ubuntu系列的服务器，rpm指令是无效的，输入后只会返回空白内容，之前没区分系统差异，硬套指令白白浪费了十几分钟。这类系统需要用dpkg --list | grep jdk来查询，才能正常读取到本机安装的所有jdk版本信息，这也是很多教程不会细说的细节。
排查完所有版本、卸载了冲突的旧jdk、对齐好开发和线上环境的版本之后，重新上传项目包，服务器终于跳出了成功启动的日志提示。
关掉远程终端的那一刻，只觉得基础运维的细节真的不能偷懒，越是简单的操作，越容易因为轻敌出问题。