已有 Eclipse Java 工程迁移到 VS Code，打扫干净屋子再请客

这是一个全新的时代，想在新时代里奋勇前行，唯有清掉旧包袱，轻装上阵。不然，会在很多莫名其妙的地方膈应你一下。

已有 Eclipse 工程转到 VS Code，最佳实践就一个：重新来！

否则，后续指不定给你整出啥幺蛾子，就比如：简单新加个资源路径（Resource Root），死活都没反应，加不进去。

从 Eclipse 切换过来的工程，目录下都会带着 .project 和 .classpath 两个文件。别看它们人畜无害的样子，其实这就是祸根所在！

编译输出也沿用了 Eclipse 的习性，放在了 bin 目录下面。

此时，一切静好，看起来都是正常的。能编译，能跑。

但是，你想加一个新 resources 的路径，添加资源，它没有任何变化变化，也没编译，JAVA PROJECTS 视图里也没显示新增的资源根路径（src/main/resources）。

把能想到的各种手段都用上：Java 的 Clean Workspace 以及 Gradle 的 Reload ，通通没作用。

那问题到底出在哪里了呢？

回到最初。

我们知道，Eclipse 是通过 .classpath 和 .project 来管理工程的。而且，VSCode 的 Java 插件，底层同样使用的 JDT，那有没有一种可能，被血脉压制了🤔？就是它先复用目录下已有的 Eclipse JDT 配置呢？

试一把！

清理掉已有 Eclipse 的配置， 运行 gradle cleanEclipse （如果希望带错运行，需要关闭Build Server）。

立竿见影，JAVA PROJECTS 视图自动刷新出现了 src/main/resources 路径节点。

运行一下，build 目录下产生 classes 和 resources，以及构建的运行的文件。

那是不是说 VSCode JDT 就不需要 .classpath 和 .project 的文件了呢？

非也。

我们看不到，不表示它不存在。

进到 IDE 的数据目录，比如 Cursor 的应用数据目录：C:\Users\P16\AppData\Roaming\Cursor\ ，查找我们的工程名称：test-java-project，就能看到当前工程的 JDT 配置相关的信息了。

如果遇到工程自动导入失败，必然是出错了。这是不要瞎猜，直接借助日志来排查。打开 Output  面板，切换到 Gradle for Java 进行查看。

错误是找不到 Gradle，可能是其他同事路径和你的不一致。

所以，最难的最繁琐的往往就是配置环境。一个不起眼的小配置，可能会让我们白白耗费几天。因此，Eclipse 工程迁到 VS Code，真不是“能打开就以为大功告成了”。

旧时代留下的雪糕桶，不会立刻绊你，但很可能在你最不经意的地方划你一下。

清理打扫干净，再重新开始。不是无情，而是对自己、对未来、也对过去负责。