Eclipse 能启动，不代表工程使用了正确的 JDK。编译通过而服务器报类版本错误，往往是环境不一致。
本文使用Java Web 小项目的演示工程与协作场景。初入团队时，重要的不只是写出功能，还包括让别人能够复现、审查和接手。本文使用匿名任务说明工作方法，不指代某家公司的内部流程或真实交付成绩。
1. 从现象推到机制
IDE 自身运行的虚拟机、工程构建路径、编译目标级别和应用服务器运行时可以分别配置。class 文件目标版本高于部署 JVM 支持范围，就无法加载。只修改系统 JAVA_HOME 未必改变工作区已有配置。
图中的四个节点分别表示IDE 虚拟机、工程配置、服务器运行时、版本对照。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
以 JDK 7 工程为例，核对 Installed JREs、Java Compiler 与服务器 Runtime。再查看命令行 java 和 javac 的实际版本。
1
2
3
4
java -version
javac -version
# Eclipse: Project Properties -> Java Build Path
# Eclipse: Project Properties -> Java Compiler
示例命令需要在独立演示工程中执行，路径和服务均由读者准备。操作前保留当前版本与输入，修改后对照原来的问题验证，而不是只证明新代码能够编译。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| IDE 编译成功但服务器加载失败 | 先比较目标字节码与运行时版本 |
| 修改系统变量后工程没变化 | 工作区可能仍指向旧 JDK |
| 导入工程后缺依赖 | 需要核对构建配置而非复制随机 jar |
对照 1：IDE 编译成功但服务器加载失败
先比较目标字节码与运行时版本。观察时记录完整 UnsupportedClassVersionError。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：修改系统变量后工程没变化
工作区可能仍指向旧 JDK。观察时记录工程与服务器的显式配置。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：导入工程后缺依赖
需要核对构建配置而非复制随机 jar。观察时记录项目依赖来源与版本。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
工作区个人设置不宜全部提交。可共享的是工程必要配置与构建描述，机器路径应通过环境或工具约定解决。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“导入工程后缺依赖”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
