企业官网建设流程全解析

1. 为什么我建议用 VS Code 跑 Spring Boot

先说实话，前几年我碰见 Java 项目第一反应就是打开 IDE（集成开发环境），毕竟 Java 开发配一套完整的开发工具链确实省心。但接触 VS Code 久了以后，我发现对于 Spring Boot 这种偏轻量、偏微服务、偏云原生的项目，VS Code 反而是个很好的选择。

不是说要你彻底抛弃 IDE，而是 VS Code 有几个点特别戳中实际开发场景。第一，启动速度快，打开一个大型项目基本两三秒，不会出现等半天进度条的情况。第二，内存占用低，8G 内存的机器跑 IDE 再开几个服务就很吃力了，VS Code 加两三个 Java 进程还比较从容。第三，对 Git 的操作集成做得不错，日常分支切换、冲突解决、代码审查都很顺手。第四，也是最重要的一点，它能直接复用你现有的 Maven 或 Gradle 配置，不会像导入新环境那样动不动就重新索引半天。

这篇文章我会按我自己的实操路径，把在 VS Code 里从零运行一个 Spring Boot 项目的全过程写清楚，包括环境配置、插件安装、项目导入、运行调试、以及几个我踩过的坑。无论你是刚接触 Java 还是想从 IDE 换过来试试，这篇文章的内容都能让你少走弯路。

2. 环境准备：JDK、Maven 与 VS Code 基础配置

2.1 JDK 版本选择与安装注意点

Spring Boot 3.x 要求 JDK 17 及以上，我这边的模拟项目基本都是 JDK 17，少数老的模拟项目还停留在 JDK 8。如果你电脑上有多个 JDK 版本，一定要在 VS Code 里明确指定用哪个，不然容易出现编译版本不对、依赖解析失败等问题。

安装 JDK 时，我建议直接用发行版，不要手动去改系统 PATH 里的 Java 路径，因为 VS Code 的 Java 插件会自动扫描注册表或常见安装路径。如果你用的是 JDK 8，某些新版本的 Spring Boot 依赖会直接给你报错，提示不支持 class file 版本。说白了就是 JDK 的 major version 对应不上。Spring Boot 2.x 用 JDK 8 或 11 没问题，Spring Boot 3.x 就必须 JDK 17。

这里补充一个设置项，VS Code 里按Ctrl + ,打开设置，搜索java.home或者看java.configuration.runtimes。我实测下来，在settings.json里显式配置运行时时最稳妥的：

"java.configuration.runtimes": [ { "name": "JavaSE-17", "path": "C:\\Program Files\\Java\\jdk-17", "default": true } ]

如果你用的是 macOS 或者 Linux，路径就要改成你实际安装的位置，比如/usr/lib/jvm/java-17-openjdk-amd64。这里要留意default字段，它代表 VS Code 系列工具默认启动 Java 项目时用的运行时。如果没有标注default，系统有多个 JDK 的时候，插件可能随机选一个，那就会有各种莫名其妙的兼容性问题。

2.2 Maven 的安装与镜像配置

Maven 是 Spring Boot 项目最常用的构建工具，虽然 VS Code 的 Java 插件自带了一个内嵌 Maven 版本，但我个人还是建议你单独装一个 Maven，原因一个是命令行打包部署还是要用，另一个是自带的 Maven 在某些插件版本的兼容性上偶尔抽风。

安装 Maven 本身不复杂，下二进制包解压，然后把bin目录加到 PATH 就行。核心的配置在conf/settings.xml，我重点说三个必改项。

第一个是本地仓库路径。默认会把你用户目录下的.m2/repository作为本地仓库，但如果你的 C 盘空间不太够，或者你想把仓库放到机械硬盘或移动固态里，就要改localRepository标签的内容。

第二个是镜像。国内网络环境下直接访问 Maven 中央仓库偶尔会很慢，强烈建议配一个国内镜像。以阿里云仓库为例：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/central</url> </mirror>

这里我不展开推荐哪个镜像，因为不同网络环境下差别还挺大的。但有一个调试技巧，如果项目明明有依赖却一直解析失败，可以先看看是不是镜像仓库只镜像了中央仓库，没镜像 Spring 的里程碑仓库。Spring Boot 有些预览版本依赖会从spring-milestones仓库拉取，你要么在pom.xml里加上这个仓库，要么在镜像配置里加上对应的mirrorOf。

第三个是代理设置。如果你的开发环境处在内网，必须走代理才能访问外网资源，那 Maven 也需要配 HTTP 代理，不然下载依赖会直接超时。配置项是<proxies>标签，这个比较基础，我不展开写了。

2.3 VS Code 本体与 Java 插件组合

VS Code 装好之后，扩展商店里搜 Java，会出来好几个跟 Java 相关的扩展。我的实测组合是下面这四个，缺一不可：

• Extension Pack for Java：这是微软官方的 Java 扩展套装，包含语言服务、调试器、测试框架支持、Maven 支持等一整套能力。装上它，Java 文件就能有代码高亮、自动补全、重构、跳转定义这些基础能力。
• Spring Boot Extension Pack：这是专门为 Spring Boot 服务的，里面包含 Boot 项目创建向导、应用启动/停止按钮、实时运行信息展示、配置项提示等功能。没有这个包，你跑 Spring Boot 项目会少很多便利。
• Lombok Annotations Support：如果你的项目用了 Lombok，这个扩展必装，不然 IDE 里会大面积报错，提示找不到getter、setter、builder之类的符号。
• SonarLint：并不是必需的，但我个人建议装一个，它在写代码的时候就帮你检查潜在的 Bug 和坏味道，对长期维护项目的人很有帮助。

装完插件以后有一个关键的步骤：让插件彻底完成语言服务的初始化。第一次打开 Java 项目时，右下角会弹出提示说要导入 JDK 和 Maven 信息，等它跑完进度条再操作。我见过很多新手在这个阶段就直接点项目运行，结果还没等语言服务起来，各种语法错误提示铺天盖地，其实不是项目有问题，只是后台还没准备好。

初始化完成的状态怎么判断？最直观的标准是：打开任意一个 Java 类文件，鼠标悬停在类名或方法名上，如果几秒内能弹出签名、注释、类型信息等悬浮提示，就说明语言服务已经就绪了。另外，VS Code 左下角的 Java 语言服务状态栏图标会从"加载中"变成"已就绪"。

3. 创建与导入 Spring Boot 项目：两种路线对比

3.1 使用 VS Code 内置模板创建项目

VS Code 的 Spring Boot 扩展包提供了一个创建向导，你按Ctrl + Shift + P打开命令面板，输入Spring Initializr: Create a Maven Project，然后跟着向导选择语言、Spring Boot 版本、项目元数据（Group、Artifact、包名等）以及依赖项。

这条路线适合一个全新项目。流程上，向导会引导你选 Spring Boot 版本、项目类型（Maven 还是 Gradle）、语言（Java、Kotlin、Groovy）、Group 名称、Artifact 名称、打包方式（Jar 还是 War）、Java 版本，最后让你勾选需要的依赖，比如 Spring Web、Spring Data JPA、MySQL Driver 等。

选完以后会生成一个基础项目骨架，里面包含标准的 Maven 目录结构、pom.xml、还有带main方法的启动类。生成的位置一般是你当前打开的文件夹下。

不过我一般不会用这个向导，原因有两个。一是它生成的版本号有时候不是最新的稳定版，如果你对版本有特殊要求，还得自己去改pom.xml。二是对于我这种有自己的公司脚手架的人来说，手动从自己的模板仓库里拉项目改起来更快。

3.2 直接用 Maven 导入已有项目

如果你已经有一个 Spring Boot 项目，要把它拿到 VS Code 里运行，那步骤更简单。直接File->Open Folder打开项目根目录就行，VS Code 会自动识别pom.xml或build.gradle文件，然后开始后台导入依赖。

我自己更习惯先用命令行把最终状态验证一遍，再让 VS Code 加载：

mvn clean package -DskipTests

为什么要先跑一次？因为 VS Code 的 Maven 插件虽然能自动下载依赖，但出问题时它的报错信息没有命令行那么直接。命令行跑一次能提前暴露依赖冲突、仓库不可达、私服认证失败这类问题。等你命令行验证能通过之后，VS Code 这边基本不会有大问题。

导入完成后，VS Code 左侧会多出一个资源管理器视图，这就是 Maven 插件的面板，里面按逻辑结构列出了项目的依赖树、生命周期目标（clean、compile、package、install等）和插件目标。双击某些生命周期目标就能直接执行，比如在 Maven 面板里右键package选运行，效果等同于在命令行敲mvn package。

3.3 项目结构识别与资源配置

VS Code 不像 IDE 那样有一个 "Project Structure" 的明确窗口，它靠的是文件夹本身的结构。Spring Boot 项目的标准结构如下：

my-project/ ├── pom.xml ├── mvnw ├── mvnw.cmd ├── .mvn/ │ └── wrapper/ ├── src/ │ ├── main/ │ │ ├── java/ │ │ │ └── com/example/demo/ │ │ │ ├── DemoApplication.java │ │ │ └── controller/ │ │ └── resources/ │ │ ├── application.properties │ │ ├── application-dev.yml │ │ └── static/ │ └── test/ │ └── java/

VS Code 会直接按照这个文件夹结构在工作区里展示，所以你需要自己留意分层。有一个技巧是把常用文件夹添加为工作区（File->Add Folder to Workspace），这样就不用每次一层层点进去找src/main/java了。

关于 Spring Boot 的配置文件，我建议用application.yml，因为它比application.properties更容易读，而且支持多文档块。VS Code 的 Spring Boot 插件对 yml 文件有专门的配置项提示，你输入server.port这类前缀，它会自动联想后续属性和合法取值。这个功能对刚接触 Spring Boot 的人能省很多查文档的时间。

4. 运行 Spring Boot 项目：几种方式与适用场景

4.1 主类直接运行

项目导入并构建成功后，最直接的运行方式是打开带有@SpringBootApplication注解的启动类，看代码上方有没有Run和Debug按钮，点了就直接跑。

如果没有显示这两个按钮，可能是因为启动类没有被识别为主类。这时候可以右键启动类文件，选择Run Java，或者打开命令面板搜索Java: Run。如果右键菜单里也找不到，多半是 Language Server 还没把项目加载完，等它加载完再来重启 VS Code 或者重新加载窗口。

启动以后，Debug Console面板会输出 Spring Boot 的启动日志，你能看到内嵌的 Tomcat 什么时候启动、端口号是什么。默认端口是8080，如果你本机没占端口，启动日志最后会出现类似Tomcat started on port 8080 (http) with context path ''这行。

注意：直接运行主类的方式用的是项目的classpath和 VS Code 当前的运行配置，不会走mvn package产出的那套部署流程。如果你项目里有代码生成、资源过滤等 Maven 插件逻辑，直接运行时可能不会完全生效。

4.2 Spring Boot Dashboard 面板运行

装了 Spring Boot Extension Pack 之后，VS Code 左侧边栏会出现一个 Spring Boot Dashboard 的图标，点开以后可以看到当前工作区里所有被识别到的 Spring Boot 项目。

每个项目会显示当前状态（Running 或 Stopped）、启动类名称、运行的端口。点击项目右边的三角形按钮就能启动，点方块按钮就能停止。这个面板的好处是你能管理多个微服务，比如一个 Gateway、一个服务注册中心、几个业务微服务，同时启动和停止非常方便，不用切终端窗口挨个操作。

如果你启动时报错，面板里会显示红叉，点开可以看到具体日志。我见过很多人启动失败后去翻系统日志，其实 Spring Boot Dashboard 里给出的错误信息往往已经足够定位了。

4.3 使用 Maven 插件跑spring-boot:run

这种方式适合需要完整走一遍 Maven 构建流程的场景。你可以在终端里直接输：

mvn spring-boot:run

也可以在 Maven 面板里找到spring-boot插件下的run目标，双击执行。两种方式效果类似，都会重新读取pom.xml，执行编译、资源处理、启动等阶段。

这种方式有几个好处：第一，能准确复现命令行环境下的行为，某些依赖只有通过 Maven 构建才会正确加载。第二，可以通过命令行参数覆盖配置，比如：

mvn spring-boot:run -Dspring-boot.run.profiles=dev

把dev换成你自己的 profile 名即可。不过这命令只能从命令行传，VS Code 的 Maven 面板双击执行时是不能交互式传参的，如果你想传-Dspring-boot.run.profiles=dev，还是建议直接在终端跑。

4.4 远程调试模式

运行 Spring Boot 项目时如果需要跳过前端静态资源的编译等等，可以用 JVM 参数直接把一个普通的可运行 Jar 跑起来：

java -jar target/demo-0.0.1-SNAPSHOT.jar

VS Code 也支持对这样的进程做远程调试，只要你启动 Jar 时加上调试参数：

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar target/demo-0.0.1-SNAPSHOT.jar

然后在 VS Code 的.vscode/launch.json里配置一个attach类型的调试配置：

{ "type": "java", "name": "Attach to 5005", "request": "attach", "hostName": "localhost", "port": 5005 }

这样你就能在本地代码里打断点、看变量、单步调试，对排查线上问题或者调试本地独立启动的外部进程很有用。

5. 配置 launch.json：端口、环境变量与命令行参数

5.1 生成 launch.json 的时机

很多初学者不知道 launch.json 怎么出现。实际上，当你点过Run按钮之后，VS Code 会自动生成一个.vscode/launch.json，里面包含一个"type": "java"的默认配置。

如果你想手动配置，也可以创建这个文件。launch.json是 VS Code 的调试配置文件，它定义了用什么方式启动或附加到程序、传什么参数、配什么环境变量。对 Spring Boot 项目来说，最常用到的就是指定启动类、指定 profile、指定端口覆盖、指定环境变量。

5.2 一个可直接改用的 launch.json 模板

下面是我在模拟项目里常用的一套配置，你可以直接复制过去改成自己的启动类：

{ "version": "0.2.0", "configurations": [ { "type": "java", "name": "Launch DemoApplication", "request": "launch", "mainClass": "com.example.demo.DemoApplication", "projectName": "demo", "args": "--spring.profiles.active=local --server.port=8081", "env": { "DB_HOST": "localhost", "DB_PORT": "3306", "APP_LOG_LEVEL": "DEBUG" }, "vmArgs": "-Xmx512m -Xms256m" } ] }

逐项说明一下：

• mainClass如果是多模块项目，要写完全限定类名，比如com.xxx.gateway.GatewayApplication。
• args里写的参数会被当作 Spring Boot 的命令行参数处理，优先级比配置文件高，可以临时覆盖端口、启用 profile。
• env是环境变量，不是 Spring 属性。如果你的配置文件里引用了${DB_HOST}这类占位符，可以用这里传入实际值。
• vmArgs是 JVM 参数，如果你默认内存不够需要调大，可以在这里改。

注意：vmArgs里如果要传-D系统属性，不要写到args里。Spring Boot 的命令行参数解析方式和 JVM 系统属性是两个不同的机制，混了会导致配置读取不到。

5.3 多环境配置与 Profile 切换

Spring Boot 的 Profile 机制在 VS Code 里用起来其实不复杂。你在src/main/resources下放多个配置文件，比如application.yml是基础配置，application-dev.yml是开发环境覆盖，application-prod.yml是生产环境覆盖。

在 launch.json 的args里加上--spring.profiles.active=dev，启动时就会优先读取application-dev.yml。

我自己的经验是：开发环境用devprofile，本机服务、数据库配置写成最方便联调的形式；预发和线上配置不要放进代码仓库，而是通过环境变量或者配置中心注入。这样本地跑起来永远数据安全，线上配置也不会被误改了开发环境。

5.4 外部化和敏感配置的处理

Spring Boot 的配置有一个优先级顺序，从上到下大致是：命令行参数 > Java 系统属性 > 操作系统环境变量 > 配置文件 > 内置默认值。

所以在本地开发时，你完全不用把真实的数据库密码写进application.yml。我一般这么做：application.yml里写好占位符（比如${MYSQL_PASSWORD}或者${DB_PASSWORD}），在 launch.json 的env里传入本机测试密码。这样哪怕整个项目发给别人，敏感信息也不会泄漏。

如果是多人协作，大家各自维护自己的launch.json，不要提交到 Git。可以在.gitignore里加上.vscode/launch.json（如果你不想把调试配置共享到团队的话）。我个人的习惯是.vscode/文件夹下只共享extensions.json和settings.json，launch.json自己留着。

6. 实操中常见的报错与排查记录

6.1 无法识别为 Java 项目

症状：打开项目以后，所有 Java 文件都没有语法高亮，右键没有 Build 相关选项，Spring Boot Dashboard 里什么都看不到。

排查步骤：

1. 先确认右下角 Java 语言服务状态是"已就绪"，如果不是就点它重新初始化。
2. 打开命令面板，执行Java: Clean Java Language Server Workspace，清理工作区缓存再重载窗口。
3. 确认项目根目录下有pom.xml或build.gradle，如果文件不在根目录（比如嵌套子目录里），需要在.vscode/settings.json中通过java.project.referencedLibraries指明路径。

最常见的原因是中途切过项目、Maven 仓库损坏、或者语言服务的数据和磁盘上的实际依赖不一致。清理缓存以后一般能解决。

6.2 端口被占用

症状：启动日志提示Port 8080 was already in use，或者Web server failed to start。

解决方式：

# Windows netstat -ano | findstr :8080 taskkill /F /PID <PID> # macOS/Linux lsof -i :8080 kill -9 <PID>

如果你有多个服务要同时跑，建议不要都占默认端口。在配置里给每个微服务指定独立的端口，Spring Cloud 系的项目尤其要提前规划好端口占用表，不然联调的时候天天因为端口冲突瞎折腾。

6.3 Maven 依赖下载失败

症状：pom.xml文件顶部出现错误标记，Problems 面板提示Cannot resolve symbol或者Failure to find ...某个依赖。

处理办法：

1. 打开 Maven 面板，找到Reload All Maven Projects，先重新加载一次。
2. 如果还不行，到本地仓库对应目录下看看是不是有.lastUpdated后缀的文件残留，有的话说明上次下载失败了，把整个相关目录删掉重新拉。
3. 检查 Maven 的settings.xml里镜像配置是否正确，以及仓库地址是否能访问。
4. 检查项目所用私服仓库是否需要在pom.xml里专门配置repository标签。

有时候问题出在代理上：VS Code 的 Java 插件去下载依赖时走的是系统网络配置，而 Maven 命令行走的是settings.xml里的代理配置。两边不一致就会导致 IDE 里报错、命令行反而正常。

6.4 中文乱码问题

症状：终端里中文输出变成乱码，或者源码里的中文字符串变成?。

原因一般有两个，一个是控制台编码，一个是文件编码。Spring Boot 项目源码如果用的是 UTF-8，那么你的 VS Code 工作区编码也要设置成 UTF-8。在.vscode/settings.json里加上：

"files.encoding": "utf8", "files.autoGuessEncoding": true

Windows 控制台乱码问题，通常是因为系统默认代码页是 GBK。这时候要么改 VS Code 终端输出编码，要么在启动配置里的console选项中选择internalConsole而不是integratedTerminal。我实测下来，在 Debug Console 窗口里显示的中文一般不会乱码，所以拿集成终端跑应用如果发现乱码，就切到 Debug Console 里看。

6.5 Lombok 相关报错

症状：代码里用了@Data、@Builder、@Slf4j等注解，但是没有生成对应的方法，编译时提示找不到log或者getter/setter。

首先要确保你的项目里 Lombok 依赖的版本和 JDK 版本兼容。JDK 17 及以上对应 Lombok 1.18.20 以上，版本太低会出现不可预料的编译失败。其次确保 VS Code 里装了 Lombok 支持扩展，并且开启语言服务的相关设置。

我见过一个典型的案例：项目从 JDK 8 升到 JDK 17 以后，Lombok 没升级，结果编译时报java.lang.ExceptionInInitializerError，看起来像是环境问题，实际上是 Lombok 版本不支持新 JDK 的字节码操作方式。

6.6 调试时断点不生效

症状：把断点打在 Java 文件里，启动后请求走了对应的代码路径，但断点没触发。

原因往往是以下三种情况之一：

1. 断点所在行没有实际字节码（比如空行、注释行、声明行），换到有执行代码的行。
2. 你直接用java -jar启动的进程没有带-agentlib:jdwp参数，VS Code 里的 Attach 配置连不上。
3. 本地代码和实际运行的 Jar 版本不一致，符号对不上。

第一种情况最常见，新手喜欢把断点打在}上，那是无效的。还有种情况是热部署搞的鬼——你用了 DevTools，改了代码自动重编译以后，断点的类加载器变了，调试会话还停留在旧的类信息上，重启调试会话就好。

6.7 常见问题速查表

7. 热重载与开发效率提升技巧

7.1 引入 Spring Boot DevTools

Spring Boot 官方提供的spring-boot-devtools能在代码修改后自动重启应用，省去手动重启的时间。

在pom.xml里加：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency>

然后启动应用后，修改代码保存，VS Code 会自动编译变更的类并触发 DevTools 重启。日志里会有一行Restarting SpringBootApplication，表示热重载已经生效。

注意一点，DevTools 的重启不是完整的 JVM 重启，它是用一个自定义类加载器重新加载了应用层的类，所以速度会比冷启动快很多，但如果你改了依赖版本、增加了新依赖、或者调整了 Maven 插件的配置，DevTools 无法识别到变化，还是需要手动重启一次。

7.2 Java Language Server 的增量编译优化

想让热重载更流畅，建议在.vscode/settings.json里开启 Java 编译到输出目录的选项：

"java.compile.nullAnalysis.mode": "disabled", "java.autobuild.enabled": true

autobuild默认是开的，它能在文件保存后触发增量编译。如果哪天发现保存代码后服务没有自动重启，先检查这个设置是不是被你自己关掉了。

7.3 常用快捷键与命令速记

我把自己日常使用频率最高的几个操作列出来：

有一个很实用的功能是Java: Go to Super Implementation，在接口方法上使用可以快速跳转到实现类，代码阅读效率能提升不少。

7.4 多模块项目的运行策略

Spring Boot 微服务项目一般会拆成多个模块，比如common、gateway、service-a、service-b。如果你以前用 IDE 跑这种项目，需要按顺序一个一个启动，在 VS Code 里用 Spring Boot Dashboard 会更直观。

先把整个项目作为一个文件夹打开，确认语言服务加载完成，再打开 Dashboard，你会看到所有包含启动类的模块都列出来了。按实际依赖顺序启动它们，前端调接口时注意网关端口和具体服务的端口映射。

多模块项目有一个容易踩坑的点：模块间的依赖关系有时候在本地仓库里没有。你改了 B 模块的代码，但 A 模块依赖的 B 还是旧版本，这时候要在 Maven 面板里找到 B 模块先执行install，把最新版本装到本地仓库，再让 A 模块依赖到新版本。或者在根目录跑一次mvn clean install -DskipTests，把全部模块装进本地仓库，一劳永逸。

8. 我踩过的一些坑和最后的小建议

用了很长一段时间的 VS Code 跑 Spring Boot 后，我的整体感受是：这个组合完全能应付日常开发，尤其是轻量级微服务、快速原型、临时 Demo 这类场景。但如果你做的项目非常大、模块极多、重构频繁，那 IDE 的深度索引和重构工具依然是更顺手的选择。毕竟工具靠谱与否，取决于你的核心工作流。

给我印象最深的一次排查经历，是某个模拟项目在 VS Code 里能正常编译，但mvn package出来以后启动就报类找不到。查了半天发现是 Maven 的资源过滤把application.yml里的占位符@project.version@做了解析，而 VS Code 里的运行方式跳过了这一层处理。后来我把pom.xml里的maven-resources-plugin配置补齐以后，两边行为才对齐。这类问题很难从报错直观看出来，遇到莫名其妙的"能跑但打不了包"或反向情况，先想到 Maven 生命周期和 IDE 直接运行的区别。

最后再分享一个我个人的实操小技巧。在launch.json里我习惯启动参数加上一行：

"console": "internalConsole"

然后打开 Debug Console 面板跑项目。这样服务的日志跟 VS Code 的调试输出混在一起，会带时间戳。排查问题的时候，你能同时看到断点命中的日志和应用的输出，比在两个面板之间来回切方便得多。

这篇文章讲到的内容，基本覆盖了我在 VS Code 里运行 Spring Boot 项目会碰到的全部环节。配置这块"一次配好、长期复用"是关键，JDK 和 Maven 的底子打好，后面插件和项目本身都不太会出幺蛾子。如果你在照着操作的过程中遇到别的报错，先按第 6 节的方式自查一轮：语言服务状态、Maven 仓库状态、启动端口占用、配置文件解析，九成问题都出在这几个点上。