前段时间重构旧项目的时候，被环境适配问题折腾得头大，反复纠结该如何查看java版本，还因为搞错本地Java版本，白白浪费大半天的调试时间，现在回想起来依旧觉得憋屈。
一开始压根没摸清门路，脑子里只模糊记得Java有好几个版本，8、11、17都是市面上用的最多的版本，但完全不知道怎么精准确认电脑里装的究竟是哪一个。最开始犯了个特别低级的错误，直接去文件夹里找Java的安装目录，盯着一堆看不懂的程序文件瞎翻，试图从文件名里找出版本相关的信息。
现在想想这个操作纯粹就是白费功夫。安装目录里的文件繁杂又零散，光靠肉眼筛查，别说找版本号了，连哪个文件夹是主运行程序都很难分辨，折腾半个多小时，最后什么有用的信息都没挖到。
很多人其实都不知道，电脑里会存在两套不一样的Java版本，这也是大部分人配置项目翻车的根本原因。
系统层面会预装一套公共Java环境，开发者自己还会手动下载一套专属版本，有时候改了环境变量，项目调用的依旧是系统默认的那一个，版本不匹配就会直接报错。之前就是卡在这个点上，明明刚更新了新版Java，运行项目还是一直抛出兼容异常。
后来才反应过来，不同操作系统对应的查询指令有细微差别，只用一条指令根本没办法覆盖所有场景。
Windows系统的操作最简单，直接调出cmd命令窗口，输入java -version，按下回车之后，屏幕上会直接弹出完整的版本信息，包括JDK版本、运行环境、开发厂商之类的全部内容。就两三秒的事，远比翻文件夹高效百倍。
macOS的操作逻辑大体一致，打开终端就行，不过有个小细节，部分旧版mac环境，直接输入指令没有反应，得换成/usr/bin/java -version才能正常读取数据。
最容易被忽略的一点，也是之前踩过最深的坑。上面的指令只能查到正在被系统调用的运行版本，没办法确认编译版本。如果要排查项目编译报错的问题，必须额外输入javac -version，这个指令对应的才是编译器版本。
绝大多数报错的源头，就是运行版本和编译版本不一致，比如运行环境是Java8，编译器却是Java11，日常开发里这种细微的冲突肉眼根本察觉不到，只能靠着两条指令逐一核对。
之前一直傻傻分不清这两个指令的区别，调试项目的时候，只查了运行版本，自以为环境配置没问题，结果后续打包、测试环节接连出问题，来回卸载重装三四次Java安装包，心态直接崩了。
还有个很鸡肋的查询方式，顺带提一嘴。直接在控制面板或者系统设置里，查看已安装的应用程序，能看到Java的基础版本。但这个方式只能看到简略版本号，看不到编译环境、虚拟机参数这些开发必备的信息，只适合完全不懂代码的新手简单查看，做项目开发的话完全不推荐。
忙活这么久之后，现在排查Java环境问题已经形成固定习惯。每次新建项目、切换开发分支之前，都会先后输入两条指令，核对运行和编译版本，确认二者统一之后，才会开始编写代码。
手边的水杯早就凉透了，盯着终端页面上两行整齐的版本数据，终于不用再被莫名其妙的兼容问题牵绊，直接打开IDE开始着手新项目的初始化工作。