Java博客项目实战｜工程环境与构建：工程目录、PowerShell命令调用与JDK/IDEA/Maven工作机制

文章目录

• • 一、先确定"项目"在电脑上究竟是什么
  • • [1. 压缩包、实际工程目录、教师原件与个人开发副本](#1. 压缩包、实际工程目录、教师原件与个人开发副本)
    • [2. 工程根目录、`src` 与 `pom.xml` 的身份](#2. 工程根目录、src 与 pom.xml 的身份)
    • [3. 文件与执行证据是不同层级](#3. 文件与执行证据是不同层级)
  • 二、Shell、工作目录与命令的基本结构
  • • [1. Windows PowerShell 在做什么](#1. Windows PowerShell 在做什么)
    • [2. 为什么有时写 `-`，有时写 `--`，有时不写](#2. 为什么有时写 -，有时写 --，有时不写)
  • [三、命令名字、字符串、程序路径与 `&`：多轮追问的核心](#三、命令名字、字符串、程序路径与 &：多轮追问的核心)
  • • [1. 区分三个对象：文本值、文件、调用操作](#1. 区分三个对象：文本值、文件、调用操作)
    • [2. PowerShell的表达式语境与命令语境](#2. PowerShell的表达式语境与命令语境)
    • [3. `&` 的精确含义：调用运算符（Call Operator）](#3. & 的精确含义：调用运算符（Call Operator）)
    • [4. 为什么带引号的路径后直接写 `-version` 会报错](#4. 为什么带引号的路径后直接写 -version 会报错)
    • [5. 程序路径与命令搜索：`java`为何默认找到Java 8](#5. 程序路径与命令搜索：java为何默认找到Java 8)
  • 四、JDK、JRE、JVM、Java编译和运行是哪些对象
  • • [1. 它们各自负责什么](#1. 它们各自负责什么)
    • [2. 多个Java版本能在同一台Windows电脑上共存](#2. 多个Java版本能在同一台Windows电脑上共存)
  • [五、IDEA自身的JBR，与博客项目的Project SDK](#五、IDEA自身的JBR，与博客项目的Project SDK)
  • • [1. IDE是一个程序，博客也是另一个程序](#1. IDE是一个程序，博客也是另一个程序)
    • [2. Project SDK / Language Level](#2. Project SDK / Language Level)
    • [3. 共享JDK安装目录，不等于共享一个JVM进程](#3. 共享JDK安装目录，不等于共享一个JVM进程)
  • 六、Maven初识：一个项目为什么需要构建工具
  • • [1. Maven不是Java编译器](#1. Maven不是Java编译器)
    • [2. `pom.xml`的作用](#2. pom.xml的作用)
    • [3. 构建脚本和工具配置](#3. 构建脚本和工具配置)
  • 七、项目导入、构建、编译、测试、打包、生命周期：区别与因果
  • • [1. 导入（Import）](#1. 导入（Import）)
    • [2. 编译（Compile）](#2. 编译（Compile）)
    • [3. 构建（Build）与打包（Package）](#3. 构建（Build）与打包（Package）)
    • [4. Maven构建生命周期（Lifecycle）](#4. Maven构建生命周期（Lifecycle）)
  • [八、Maven Importer、Runner、Project SDK与应用运行JDK](#八、Maven Importer、Runner、Project SDK与应用运行JDK)
  • • [1. 各项设置对应不同执行活动](#1. 各项设置对应不同执行活动)
    • [2. 三种JDK是不是必须完全相同](#2. 三种JDK是不是必须完全相同)
    • [3. IDEA可以同时有Maven活动和博客Java进程吗](#3. IDEA可以同时有Maven活动和博客Java进程吗)

一、先确定"项目"在电脑上究竟是什么

1. 压缩包、实际工程目录、教师原件与个人开发副本

老师提供的课程源码压缩包包含许多技术案例和目录。已在其中定位到单体博客案例，其原始相对位置为：

spring-cloud-master/
└── Spring Cloud一期 代码&板书&资料/
    └── 案例练习资料/
        └── 后端spring-blog/
            ├── pom.xml
            └── src/
                └── main/

ZIP 是文件及其目录关系的归档容器。能在 ZIP 内看到 pom.xml 和 src，只证明压缩包中包含对应条目；只有把它正确提取到 Windows 文件系统，才得到可供 IDE 和构建工具正常访问的实际目录。

提取后同样不能仅凭文件存在就断定项目已经能够编译、启动。

当前已知老师原始工程的位置为：

D:\保存文件\Java微服务项目学习与实战开发\老师原始源码\spring-cloud-master\Spring Cloud一期 代码&板书&资料\案例练习资料\后端spring-blog

实际建立的个人开发副本位置为：

D:\JavaBlogWork\spring-blog

两者可能有相同的文件和目录结构，但属于两组不同的文件对象 。老师原件是比较、参考及必要时的恢复依据；个人副本用于后续修改、编译、调试和测试。

复制应使用"复制---粘贴"，避免移动老师原件；在目标已有同名文件时不得不核验便合并或覆盖。将个人开发路径设为较短的英文路径，可减少某些工具和脚本面对空格、特殊字符或过长路径时的兼容性问题，但不意味着中文或带空格路径必然无法使用。

2. 工程根目录、src 与 pom.xml 的身份

当前单体博客副本的大致结构为：

D:\JavaBlogWork\spring-blog\
├── pom.xml
└── src\
    └── main\
        └── java\
            └── com\bite\blog\SpringBlogApplication.java

包含当前项目主 pom.xml 的 spring-blog 目录，是这个 Maven 单体工程通常所说的工程根目录 。src 放置源代码和相关资源，其中 src/main/java 通常放置主要 Java 源码。

pom.xml 是构建描述文件，不等于可直接启动的程序 ；而 SpringBlogApplication.java 是此前已经定位到的 Spring Boot 主启动类源码文件，文件存在亦不等于应用已成功启动。

老师源码顶层目录名为 spring-cloud-master，并不使内部的每一个技术案例都自动成为当前 P0 项目。当前批准的业务目标是 Spring Boot 单体博客，微服务化属于后续有条件的 P1 扩展；不能因源码包名称就提前部署全部分布式组件。

3. 文件与执行证据是不同层级

实际在 PowerShell 中执行过：

Test-Path -LiteralPath 'D:\JavaBlogWork\spring-blog\pom.xml'
Test-Path -LiteralPath 'D:\JavaBlogWork\spring-blog\src\main\java\com\bite\blog\SpringBlogApplication.java'

两次返回 True，证明指定的两个路径在检查时存在。Test-Path 负责查询路径存在性；-LiteralPath 使给定路径按字面文字解释，而不把其中字符当作通配符模式。

它不会编译文件，也不能只凭这两条结果证明目录里每个文件已完整复制。后续构建、运行和业务测试必须分别取证。

二、Shell、工作目录与命令的基本结构

1. Windows PowerShell 在做什么

PowerShell 是一个能够接收命令、解析输入并调用相应命令或程序的 Shell。它维护当前会话的当前工作目录 ，并按照语法解析、命令查找及参数传递等规则执行输入。

当前工作目录不是 Java 安装目录，也不必等于 Maven 工程根目录。

Get-Location

Get-Location 是 PowerShell Cmdlet，按惯例采用 动词-名词（Verb-Noun）命名方式；连字符属于整个命令名称 ，因此 Get-Location 和 Get -Location 并不等价。类似例子还有 Get-Process、Get-Service、Set-Location。

Get-Location 查询的是当前 PowerShell 位置，不会自动移动文件、修改工程或切换目录。当前会话位置会影响相对路径的解释。

比如在工程根目录执行 mvn package 时，Maven通常从当前目录读取 pom.xml；也可以通过参数明确指定其他 POM。命令实际在哪个目录执行，是判断它处理哪个工程的重要条件。

2. 为什么有时写 -，有时写 --，有时不写

Get-Location
java -version
mvn -version
git --version
git status

这里的符号角色不同：

输入形式	解析要点	含义来源
Get-Location	一个完整的 Cmdlet 名称；中间 - 用于命名	PowerShell 的 Cmdlet 命名约定
java -version	java 是要调用的命令，空格后 -version 是它的选项	Java 自己规定选项格式
mvn -version	mvn 为 Maven 命令名，-version 请求显示版本	Maven 自己规定选项格式
git --version	--version 是 Git 支持的长选项形式	Git 的命令行接口
git status	status 是 Git 的子命令，没有连字符	Git 的子命令结构

空格在这些例子中将命令与后续参数或子命令分开；单连字符或双连字符并没有对所有程序统一生效的"必定短选项/必定长选项"强制语义。许多工具约定 -v 为短选项、--version 为长选项，但 Java 8 使用 java -version；较新的 Java 版本还支持 java --version。具体要根据这个程序 实际支持的语法判断。部分程序把单独的 -- 作为停止解析选项的分界符，它又是另一种用法。

有时后面的内容是文件路径、普通值、子命令，不一定以连字符开头。git status 中的 status 与 git --version 中的 --version 并不是同一类型的参数。

三、命令名字、字符串、程序路径与 &：多轮追问的核心

1. 区分三个对象：文本值、文件、调用操作

观察下面的 PowerShell 表达式：

'C:\Users\32868\.jdks\ms-17.0.21.0.2\bin\java.exe'

引号所包围的内容是一个字符串字面量 ：输入的源文本表达式产生一段字符串值，值恰好表示某个路径。文件系统中的 java.exe 是另一个对象------可执行文件。

字符串中的字符本身并没有启动程序的能力；还需要 Shell 接收到"调用此命令/路径"的操作。

Java 语言中的 String name = "spring-blog"; 也可以帮助区分"字符串字面量"和"由它产生的数据值"，但 Java 的字符串语法与 PowerShell 的命令解析语法不是一套规则。

2. PowerShell的表达式语境与命令语境

对比：

'java'
java -version
& 'java' -version

第一行是字符串表达式：一般只输出 java 这个字符串，没有要求执行 Java 程序。第二行的 java 位于命令位置 ，PowerShell 会把它识别为需要解析并调用的命令名称；并非先运行一条字符串打印命令，再把输出重解释成命令。

第三行先获得字符串 java 的值，接着由 & 将这个值作为命令名称调用。

因此，文本恰好拼成路径或命令名，不代表文本在任何语法位置都会被执行。Shell依据语法位置和运算符决定下一步如何处理它。

3. & 的精确含义：调用运算符（Call Operator）

& 'C:\Users\32868\.jdks\ms-17.0.21.0.2\bin\java.exe' -version

执行过程分为：

1. PowerShell识别前缀 &，进入以其操作数为命令的调用形式。
2. 引号内的表达式求值得到完整的程序路径字符串。
3. PowerShell用这个结果查找并启动相应程序，将后续 -version 作为参数传递给外部程序。
4. java.exe 自己解析 -version 的语义，输出Java版本信息。

& 不会 "取消字符串身份""逐字符重新解释内部 PowerShell 语法"或"删除字符串意义"；它使用表达式求得的值进行命令调用。由此可解释：

$program = 'C:\Users\32868\.jdks\ms-17.0.21.0.2\bin\java.exe'
$program                  # 得到路径字符串
& $program -version       # 依据变量的字符串值调用程序

也可比较：

java -version
& java -version
& 'java' -version

只要命令搜索环境相同并找到同一 java，三种写法通常调用同一个程序；后两种形式的 & 不是额外启动一遍，也不使它们进入另一个 Java 环境。& 'java' 比直接 java 多了明确使用一个字符串表达式作为命令名称的形式，而直接 java 也要经过命令查找，不能理解为跳过查找、直接执行。

反例：

& 'java -version'

PowerShell会把整个字符串 java -version 当成要调用的一个命令名称 ，不会自动拆成 java 与单独的 -version 参数；一般会报找不到命令。这验证了 & 不是"再次执行字符串里的整段PowerShell代码"。

4. 为什么带引号的路径后直接写 -version 会报错

用户实际尝试：

'C:\Users\32868\.jdks\ms-17.0.21.0.2\bin\java.exe' -version

得到 ParserError / UnexpectedToken，并提示 -version 是意外标记。原因在于开头首先被解析为字符串表达式，没有形成"调用外部程序并传入选项"的有效语法结构。这是PowerShell解析阶段的错误 ，不是Java程序已执行并拒绝了参数。

随后添加 & 后，命令成功输出Java 17版本信息。

5. 程序路径与命令搜索：java为何默认找到Java 8

命令名 java 不包含完整路径时，PowerShell会按自己的命令发现规则解析它，包括别名、函数、Cmdlet以及外部可执行程序；对于外部程序通常涉及 PATH 环境变量列出的搜索目录。不能把 PATH 理解为"直接把所有文件路径都塞到命令里"：它包含的是搜索目录等信息。

若发现对应 java.exe，才执行该文件。

java -version

用户本机此前得到 java version "1.8.0_192"，说明当时普通命令解析实际调用了Java 8。这个输出支持"当时被找到的程序是Java 8"，但不能仅凭它判断具体 PATH 顺序，或者证明机器不存在Java 17。

直接输入未加引号、无空格且语法可识别的完整路径，例如：

C:\Users\32868\.jdks\ms-17.0.21.0.2\bin\java.exe -version

PowerShell通常能将其直接识别为命令路径：不必再依赖 PATH 在多个目录中寻找同名程序，但仍需要通过文件系统定位并启动该路径所指向的文件 。

路径中包含空格时，通常应使用带引号的路径并以 & 调用：

& 'C:\Program Files\Java\jdk-17\bin\java.exe' -version

此为语法示例，不宣称该示例目录真实存在。

若路径已明确，没有空格也可使用 & '完整路径'；这种写法一致、易复制，并不因为目录没有空格而出错。

四、JDK、JRE、JVM、Java编译和运行是哪些对象

1. 它们各自负责什么

• JDK（Java Development Kit） ：Java开发工具包；通常包括运行Java所需组件、类库、java启动工具、javac编译工具等。
• Java运行环境/JRE ：面向运行Java程序所需的运行时组件的传统名称与角色。现代JDK发布包的组织方式依发行版而异，不能简单假设所有版本都在磁盘上有单独的 jre 子目录。
• JVM（Java Virtual Machine）：执行Java字节码的虚拟机；运行中的Java应用会使用相应JVM实例。
• javac ：将 .java 等Java源码编译为 .class 字节码的编译工具。
• java ：启动Java应用或执行相应Java工具功能的命令；java -version只打印版本，不启动博客业务程序。

典型链条：

Java源文件 (.java)
    ↓ 由Java编译器编译
字节码文件 (.class)
    ↓ 由兼容的Java运行环境启动、加载、执行
运行中的Java应用进程

这里"编译成功""Java程序启动""HTTP接口可访问""业务功能正确"是不同的证据层次，不能互相代替。

2. 多个Java版本能在同一台Windows电脑上共存

本轮Windows环境已经观察到：

C:\Program Files\Java\jdk1.8.0_192\              （原JDK 8）
C:\Users\32868\.jdks\ms-17.0.21.0.2\          （独立新增的Microsoft JDK 17）

用户用绝对路径分别验证：

& 'C:\Users\32868\.jdks\ms-17.0.21.0.2\bin\java.exe' -version
& 'C:\Users\32868\.jdks\ms-17.0.21.0.2\bin\javac.exe' -version

实际分别出现 openjdk version "17.0.21.0.2" 和 javac 17.0.21.0.2，证明该目录的Java运行命令和编译器命令都能够运行。与此同时，普通PowerShell中 java / javac 此前找到Java 8。

给IDEA选择新Project SDK，通常不自动修改Windows普通Shell的PATH或JAVA_HOME，因此两种现象可以并存。

五、IDEA自身的JBR，与博客项目的Project SDK

1. IDE是一个程序，博客也是另一个程序

IntelliJ IDEA是集成开发环境，提供项目查看、编辑、代码分析、编译、运行与调试等工具。它本身需要运行环境。

已观察到的IDEA版本为 2022.3.3 Community Edition ，关于窗口显示其自身使用 JetBrains Runtime（JBR）17.0.6。JBR是JetBrains基于OpenJDK、针对JetBrains产品适配的Java运行时发行版；发行形式可能包含不同工具，不能单凭"JBR 17"四个字证明当前包与独立完整JDK 17完全等同。

IDEA自身的运行环境并不是IDEA会自动登记给项目使用的JDK。IDEA能用JBR 17运行自己，Project SDK列表中仍然可能只出现JDK 8 。

Project SDK是单独管理的已登记开发工具包配置，列表没出现JDK 17也不能单凭截图断定电脑硬盘上不存在JDK 17。

2. Project SDK / Language Level

Project SDK是IDEA对当前工程使用的默认JDK配置，影响代码分析、IDE构建等活动；具体模块还可能有自己的SDK配置。Language Level用于确定Java源语言特性的允许范围，不单独保证Maven构建环境已经选择正确JDK，也不保证应用运行JVM就是它。

已在IDEA中添加 Microsoft OpenJDK 17.0.21.0.2，且项目截图显示：

Project SDK  = ms-17（17.0.21）
Language Level = SDK默认值（17）

这使项目配置符合博客工程已知的Java 17目标，但不能代替实际Maven构建验证。

3. 共享JDK安装目录，不等于共享一个JVM进程

一个JDK安装目录提供可以被不同程序/进程使用的文件。例如IDEA自身可以运行于它的JBR环境，Maven可以在另一个Java进程运行，博客应用也可以另起Java进程。

即使三个不同活动都选择相同JDK安装目录，通常也会拥有各自的进程内存和线程等运行状态。

因此，必须区分：

1. JDK磁盘安装目录：文件存放在哪里。
2. JDK/Java版本：这些工具兼容的Java版本是什么。
3. 运行中的进程/JVM实例：此刻由哪个程序使用何种运行环境执行。

"同一JDK目录"或"同为Java 17"都不能推出"就是同一个JVM"。

六、Maven初识：一个项目为什么需要构建工具

1. Maven不是Java编译器

Maven是主要用于Java生态的项目管理和构建自动化工具 。真实Java工程可能有大量源码、资源文件和外部程序库，还需要编译、测试、打包等步骤。

Maven依据项目构建配置，组织依赖准备与相应插件任务，减少人工逐条拼装这些操作。

例如博客依赖Spring Boot组件和数据库驱动时，Maven可以依据POM中的依赖声明及其他配置尝试从本地仓库或远程仓库取得需要的构件。这里的依赖 ，是当前项目使用的其他程序库或构件；不是把所有外部代码都写进自己的 .java 文件。

Maven不等于 javac：典型编译任务由Maven编译插件协调相应编译工具完成。

2. pom.xml的作用

POM（Project Object Model）是项目对象模型。pom.xml 是XML文本配置文件，包含项目身份（例如groupId、artifactId、version）、依赖、构建插件、打包方式、Java版本配置等信息。不是所有POM都必须显式列出所有配置，部分设置可能继承自父POM或采用默认值。

它告诉Maven"这是什么工程，需要哪些东西，以及应该怎样组织构建"；它不等于可运行的Java入口。spring-blog含有pom.xml，是判定它为Maven项目、找到其构建描述的主要证据，但还要读取文件实际内容才能准确判断具体依赖、插件、打包产物和配置。

3. 构建脚本和工具配置

构建脚本 可用于显式安排多个命令的执行顺序，比如PowerShell脚本依次运行 mvn clean、mvn package；这种写法是示意，不代表当前工程已执行。工具配置 规定工具工作条件，例如IDEA的Project SDK、Maven配置中的本地仓库位置、某个插件参数或编译目标版本。

Maven的POM以声明式项目模型为核心，Shell脚本则可以直接编排操作步骤。二者用途相邻但不能混为一谈。路径中的空格、引号、特殊字符在某些脚本中处理不当会导致错误，较短、简洁的工程路径是一种风险控制策略。

七、项目导入、构建、编译、测试、打包、生命周期：区别与因果

1. 导入（Import）

IDEA打开包含POM的Maven工程后，IDEA的导入/同步机制读取相关项目模型，识别依赖、模块、源码目录以及相关配置，进而在IDE内部建立可供编辑和分析的工程视图。某些项目在导入过程中也可能触发插件、代码生成等任务，但导入成功通常不等于Java源码已经编译成功，更不等于测试/打包通过。

2. 编译（Compile）

Java编译是把Java源代码转换为JVM字节码。IDEA可以通过自己的构建系统编译，也可以由Maven的相关插件配合JDK编译工具进行。编译结果一般包括 .class 文件；这些文件本身的Java类文件版本可能限制运行它的JVM最低版本。

3. 构建（Build）与打包（Package）

构建是把源码、依赖信息及相关资源按指定目标进行处理以产生软件产物的一组活动，可能包括资源处理、编译、测试、打包等。打包 只是构建中的一种特定目标，将相应产物组织成JAR/WAR等文件。

并非每次Build都要打包，也并非仅有 package 才叫Build。

mvn package表示要求Maven执行到 package 阶段；如果工程配置为JAR打包，它可能生成JAR。

但"生成一个JAR"与"生成可直接用 java -jar 启动的Spring Boot应用JAR"仍不同，后者还涉及实际Spring Boot插件和构建配置，必须通过真实POM核验。

4. Maven构建生命周期（Lifecycle）

Maven具有多个生命周期；在常见的默认构建生命周期中，阶段依先后顺序执行，例如下面是抽出的部分代表性阶段，不是全部：

validate → ... → compile → ... → test → ... → package

• validate：检查项目及相关配置是否达到构建的基本要求。
• compile：典型地执行主源码编译。
• test：典型地执行测试。
• package：典型地按指定打包类型生成产物。

请求 package 时，Maven会沿该生命周期执行到该阶段的相关任务；真正做什么依赖于阶段所绑定的插件目标和配置。"生命周期阶段"是调度结构，"插件目标"是具体执行功能，不应把两个词当成相同对象。

此前只是初步建立关系，完整阶段顺序、绑定规则与插件内部实现仍属正式Maven教学范围。

八、Maven Importer、Runner、Project SDK与应用运行JDK

1. 各项设置对应不同执行活动

对象	它是什么/管理什么	不能直接推出什么
IDEA自身的JBR	IDE程序自身的运行时	不能推出博客已使用这套JDK
Project SDK	IDEA项目开发默认JDK配置	不能单独推出Maven编译JDK和应用运行JVM
Maven Importer JDK	Maven项目导入/同步/模型处理活动的Java环境	不能推出已编译或打包成功
Maven Runner JRE	IDEA发起Maven目标执行时的Java环境	不能直接等同于IDEA运行博客主类时的环境
Application Run Configuration的JRE	IDE直接启动博客应用时的运行环境	不一定等于Maven Runner的JRE

Importer和Runner不是同一个Maven进程在"先导入---切换JDK编译---再切回原JDK运行文件"的循环阶段 。导入是建立/同步项目模型的活动，compile / package 等是另行发起的构建目标活动，而直接运行主类又属于应用启动活动。

它们可以使用相同的JDK，也可以按兼容性要求分别设置，不能不经核验就假设一定共用一个JVM。

实际IDEA 2022.3.3社区版的配置截图显示：

Maven home path: Bundled (Maven 3), version 3.8.1
Importer JDK:    Use Project SDK (17.0.21)
Runner JRE:      Use Project SDK (17.0.21)

因此当前设置画面 表示项目SDK、Importer和Runner均以JDK 17为基准。IDEA自身JBR仍为17.0.6，两者完全可以不同。

Maven 3.8.1是IDEA捆绑工具，PowerShell不识别mvn只说明该Shell未找到命令，不能证明IDEA内没有Maven；反之，IDEA里有捆绑Maven也不意味着PowerShell已经能直接运行mvn。

2. 三种JDK是不是必须完全相同

不是硬性要求完全相同，但要在各自活动中满足兼容性。例如项目采用Java 17源特性、编译目标也为17，而Maven Runner实际以JDK 8执行并且没有配置另一个可用的编译JDK，那么相关编译操作可能无法支持该目标版本。

反方向也会出问题：JDK 17编译出面向Java 17的 .class 文件，若用Java 8 JVM运行，可能抛出 UnsupportedClassVersionError，因为旧JVM不支持新类文件版本。

不同版本并非绝对不能配合：较新编译器可以在适当配置下使用 --release 面向较旧Java版本；Maven也存在Toolchains等指定编译工具JDK的能力。它们仅作为当前边界说明，后续遇到实际需求再教。

对于本博客的初次构建，使用已验证可用的JDK 17配置更容易减少版本错配，但这仍要靠实际构建结果验证。

3. IDEA可以同时有Maven活动和博客Java进程吗

可以。IDEA是一个IDE程序；Maven构建活动和博客运行活动在概念上是两个不同的过程。典型方式有：

IDEA
 ├─ 发起Maven构建：读取POM、解析依赖、调用插件、执行compile/package
 └─ 直接运行博客主类：依据应用运行配置启动博客Java进程

它们可以前后发生，也可能在博客已运行时再次发起某个构建目标；不要求所有活动使用同一个JVM，也不会仅因JDK安装目录相同就成为同一个进程。运行中的应用不会天然因为源码被重新编译就自动完成所有更新。

在IDEA的Application运行配置中，通常可以通过Before Launch任务先做必要编译，再直接运行主类；不一定每次运行前都必须执行 mvn package 。另一条路径是项目实际配置Spring Boot Maven插件时使用 spring-boot:run 等目标启动应用，具体环境与进程关系取决于插件配置和版本。

不能把"通过IDEA直接启动"和"通过Maven启动"混作同一执行方式。

实际截图里"将IDE构建/运行操作委托给Maven"没有勾选，这只影响IDEA是否默认把相应IDE操作交给Maven，并不禁止单独使用Maven构建目标，也不禁止IDEA启动博客应用。