企业官网建设流程全解析

1. 为什么“创建Java项目”这个动作，比你想象中更关键

很多人点开IntelliJ IDEA，第一反应就是找“New Project”，填个名字，一路Next——项目建好了，代码也能跑。但三个月后，当团队协作出现编译失败、Maven依赖冲突、单元测试不识别、甚至IDE突然报“Cannot resolve symbol ‘java.lang.Object’”时，回过头翻日志，八成问题就埋在那个被跳过的“新建项目”环节里。

这不是危言耸听。我带过6个校招新人，其中4个在入职第一周卡在“项目跑不起来”，不是因为不会写HelloWorld，而是因为项目骨架从根上就没搭对：JDK版本选错、语言级别设成11却用上了record语法、Maven坐标写成<version>1.0</version>却没配<packaging>jar</packaging>、甚至把src/main/java放在了project根目录下导致IDE根本识别不了源码根。这些都不是“写错代码”的问题，是“项目结构失准”的系统性偏差。

IntelliJ IDEA的“New Project”对话框，表面看是个向导，实则是Java工程生命周期的第一个决策节点。它强制你回答三个底层问题：用哪个JDK？用什么构建工具？按什么标准组织代码？这三个选择一旦确定，后续所有编码、调试、打包、部署行为都将被其约束。比如选了Gradle却手动改pom.xml，IDE会反复提示“Project files are out of sync”；选了Java 17却在module-info.java里写requires java.base;——这本身没错，但如果你没勾选“Create module-info.java”，IDE就不会生成该文件，而你手动加进去后又忘了在Project Structure里启用模块系统，编译器就会静默忽略模块声明，直到某天你发现ServiceLoader加载失败才意识到问题出在三年前建项目时漏勾了一个复选框。

所以这篇内容不叫“手把手教你新建项目”，而叫“重建你对Java项目起点的认知”。我会带你拆解每一个选项背后的工程学逻辑，告诉你为什么“JDK路径”不能只填个C:\Program Files\Java\jdk-17.0.2，为什么“GroupId”必须用反向域名格式，为什么“Add sample code”勾选框背后藏着Maven原型（archetype）的版本兼容陷阱。这不是操作手册，是帮你把IDE从“代码编辑器”升级为“工程架构师”的第一课。

2. JDK：不是“装了就行”，而是“选对版本+配准路径+验明正身”

2.1 JDK版本选择：别被“最新版”绑架，要盯住三个硬指标

打开New Project向导第一步，你会看到“Project SDK”下拉框。很多人直接点“Download JDK”，让IDE自动下载最新LTS版（比如JDK 21）。但实际开发中，这个选择可能让你在两周后陷入困境。

真正决定JDK版本的，从来不是“谁更新”，而是三个不可妥协的硬指标：

• 目标运行环境约束：你写的代码最终部署在哪？如果公司生产服务器还是CentOS 7 + OpenJDK 11，那你本地用JDK 21写出来的switch表达式（Java 14引入）或record类（Java 14正式化），上线就会报UnsupportedClassVersionError。我去年重构一个支付网关，本地用JDK 17开发，测试环境用JDK 11，结果var关键字在Lambda参数里被拒绝编译——不是语法错误，是字节码版本不兼容。

• 依赖库兼容性墙：Spring Boot 2.7.x最高支持JDK 17，3.0.x才开始拥抱JDK 19+；Lombok 1.18.28之前版本在JDK 21下会因sealed类解析异常崩溃；就连最基础的JUnit 5.7.x，在JDK 21的--enable-preview模式下运行@TestFactory方法会触发反射权限异常。这些都不是IDE报错，是运行时才暴露的兼容性断层。

• 团队统一基线要求：大厂内部通常有《Java技术栈白皮书》，明确规定“所有新项目必须基于JDK 17（LTS），禁止使用JDK 21预览特性”。这不是技术保守，而是降低协作成本——当10个开发者用不同JDK版本提交代码，CI流水线里mvn compile成功率会从99%暴跌到73%，因为javac的语法检查严格度随版本浮动。

所以我的实操建议是：先查三处。

1. 翻你们项目的pom.xml或build.gradle，看maven-compiler-plugin的source和target值；
2. 问运维同事“线上容器镜像用的JDK版本”；
3. 查团队Wiki里有没有《JDK选型指南》。
   三者取交集，才是你该选的版本。比如交集是JDK 17，那就老老实实选17，哪怕IDE提示“JDK 21提供更好性能”。

2.2 JDK路径配置：为什么“自动检测”常失效，以及如何手动验证

IDEA的“Project SDK”下拉框里，常出现“17 (17.0.2)”、“corretto-17”、“temurin-17.0.2+8”等条目。你以为选中就能用？错。这些只是IDEA读取到的JAVA_HOME环境变量指向的路径快照，它不验证该路径下JDK是否完整可用。

我遇到过最典型的失效场景：

• 公司统一安装了Amazon Corretto JDK 17，路径是C:\Program Files\Amazon Corretto\jdk17.0.2_8；
• 运维给每台机器配了JAVA_HOME=C:\Program Files\Amazon Corretto\jdk17.0.2_8；
• 但某台电脑的PATH里还残留着旧版JDK 8的bin目录，导致命令行敲java -version显示1.8；
• IDEA读取JAVA_HOME成功，显示“corretto-17”，可当你新建项目后，javac命令却调用的是JDK 8的编译器——因为IDEA的终端（Terminal）继承的是系统PATH，而非JAVA_HOME。

验证方法极其简单，但90%的人跳过：

1. 在IDEA里按Ctrl+Shift+A（Windows）或Cmd+Shift+A（Mac），输入“Terminal”打开内置终端；
2. 执行echo $JAVA_HOME（Linux/Mac）或echo %JAVA_HOME%（Windows）；
3. 执行java -version和javac -version，确认两者输出一致且版本号匹配；
4. 关键一步：执行$JAVA_HOME/bin/java -version（Linux/Mac）或%JAVA_HOME%\bin\java.exe -version（Windows），强制走JAVA_HOME路径下的二进制文件。

如果第4步输出和第3步不同，说明你的PATH污染了JDK选择。此时必须清理PATH里的旧JDK路径，或者在IDEA的Help > Edit Custom VM Options里添加-Didea.jdk.home=C:\path\to\your\jdk强制指定。

提示：不要迷信IDEA的“Download JDK”按钮。它下载的是Oracle官方JDK，而国内企业多用OpenJDK衍生版（如Temurin、Corretto、Zulu）。这些发行版的jmods目录结构、jpackage工具存在性、甚至java --list-modules的输出格式都有细微差异。手动下载对应发行版，解压后指向/jdk-17.0.2+8这样的根目录，比让IDEA自动下载更可控。

2.3 JDK与语言级别的耦合关系：一个被严重低估的隐性开关

在New Project向导里，你还会看到“Language level”下拉框，默认值常是“SDK default”。这看似省事，实则埋雷。因为JDK版本和语言级别是两个独立维度：JDK 17可以运行Java 8字节码（target=8），但无法编译Java 21的新语法（record、sealed类需source=14+）。

真正的耦合规则是：

• Language level决定IDEA语法高亮、代码补全、实时检查的规则集；
• Project SDK决定编译器（javac）能接受的最高语法版本；
• Maven/Gradle的maven-compiler-plugin或java { sourceCompatibility = '17' }决定最终生成的字节码版本。

三者必须形成向下兼容链。例如：

• 选JDK 17 + Language level 17 → 可写var、switch表达式、sealed类；
• 选JDK 17 + Language level 8 → IDE会把var list = new ArrayList<>();标红，提示“var is not supported at this language level”；
• 选JDK 11 + Language level 17 → IDE允许写record，但javac编译时报错“records are a preview feature and must be enabled with '--enable-preview'”。

我的经验是：永远让Language level等于JDK主版本号（如JDK 17 → Language level 17），除非你明确需要禁用某些特性来保持向后兼容。比如维护一个需支持JDK 8的老系统，就该把Language level锁死在8，哪怕本地装了JDK 17——这样IDEA会提前拦截所有Java 9+语法，避免误用。

验证方式：新建一个.java文件，写public record Person(String name) {}，如果IDEA不报错且能编译通过，说明Language level ≥ 14；如果报红，说明低于14。这是比查文档更快的现场测试法。

3. 构建工具选择：Maven不是唯一答案，Gradle也不是银弹

3.1 Maven vs Gradle：从“配置即代码”到“代码即配置”的范式迁移

New Project向导第二步，你会面临“Build system”选项：Maven、Gradle、Bazel、SBT……绝大多数人闭眼选Maven。毕竟“Maven是Java事实标准”，教程、面试题、公司模板都围着它转。但这个选择正在悄然改变。

Maven的核心哲学是约定优于配置（Convention over Configuration）。它强制你把源码放src/main/java，资源放src/main/resources，测试代码放src/test/java。这种强约束带来两大好处：新人上手快，团队项目结构高度统一；CI脚本可以写死路径，不用每次适配。但代价是灵活性缺失——你想把测试资源和主资源混在一个目录？不行。想用Groovy写构建脚本？得额外装GMaven插件。

Gradle则走向另一极：配置即代码（Configuration as Code）。它的build.gradle本质是Groovy或Kotlin脚本，你可以用if判断动态添加依赖，用copy { from 'src/docs' into 'build/docs' }写任意文件操作，甚至调用Java API做复杂逻辑。Spring Boot 3.0起官方推荐Gradle，原因正是它能优雅处理多模块、条件化依赖、增量编译等现代工程需求。

但Gradle的“自由”是双刃剑。我见过一个团队把build.gradle写成2000行Kotlin脚本，包含自定义插件、远程仓库鉴权、APK签名逻辑——结果新人花三天搞懂构建流程，而Maven项目新人30分钟就能mvn clean install。

所以选择逻辑很清晰：

• 选Maven：团队规模>50人、项目生命周期>3年、对构建稳定性要求极高（如金融交易系统）、CI/CD流水线已深度绑定Maven；
• 选Gradle：项目含Android/iOS跨平台模块、需频繁定制构建流程（如微前端打包）、团队有Groovy/Kotlin背景、追求编译速度（Gradle的增量编译比Maven快40%）。

注意：IntelliJ IDEA对两者的索引机制不同。Maven项目导入时，IDEA会解析pom.xml生成.idea/libraries/缓存；Gradle项目则需执行gradle idea任务生成.iml文件。这意味着——如果你用Gradle但没装Gradle Wrapper（gradlew），IDEA可能卡在“Loading project”状态长达2分钟，因为它在尝试下载Gradle分发包。务必在新建Gradle项目时勾选“Use gradle wrapper”，并确保gradle/wrapper/gradle-wrapper.properties里的distributionUrl指向国内镜像（如https://mirrors.tuna.tsinghua.edu.cn/gradle/...）。

3.2 Maven坐标（GroupId/ArtifactId/Version）：不只是命名，而是坐标系锚点

填完JDK和构建工具，向导会让你输GroupId、ArtifactId、Version。很多人随手打com.example.demo、myapp、1.0-SNAPSHOT。这看似无害，实则动摇了整个Java生态的信任根基。

GroupId本质是全球唯一的命名空间标识符，规则是反向域名（reverse DNS）。com.google.guava表示Google公司维护的Guava库，org.springframework.boot表示Spring团队的Boot模块。如果你填cn.mycompany.project，那全世界只有你公司能发布cn.mycompany.project:core:1.0这个坐标——这是Maven中央仓库（Maven Central）和私有仓库（Nexus/Artifactory）赖以运转的地址系统。

ArtifactId是项目内模块的唯一名称。它不该是“myapp”，而应体现功能域。比如电商系统，订单服务叫order-service，用户服务叫user-service，公共工具包叫common-utils。这样在pom.xml里引用时，<artifactId>order-service</artifactId>比<artifactId>myapp</artifactId>语义清晰10倍。

Version则遵循语义化版本（SemVer）规范：MAJOR.MINOR.PATCH。1.0.0表示初版稳定；1.1.0表示新增向后兼容功能；1.1.1表示修复bug；2.0.0表示破坏性变更。SNAPSHOT后缀是开发中的快照版，每次构建生成唯一时间戳（如1.0-SNAPSHOT→1.0-20240520.153022-1.jar），供其他模块实时依赖。

我踩过的坑：曾把GroupId写成mycompany（缺域名），结果在公司Nexus仓库里发布失败，报错“Invalid groupId format”。后来改成com.mycompany才通过。还有一次，把ArtifactId写成api，结果和另一个团队的payment-api冲突，CI流水线里mvn deploy直接覆盖了对方的jar包——因为Maven不校验ArtifactId全局唯一性，只认坐标三元组（GroupId, ArtifactId, Version）。

所以填这三个字段时，请默念：

• GroupId = 你公司的域名倒过来（没有域名？用io.github.yourname）；
• ArtifactId = 模块功能名，小写字母+短横线，不含空格；
• Version =1.0.0起步，开发中用1.0.0-SNAPSHOT，发布时去掉-SNAPSHOT。

3.3 “Add sample code”背后的原型陷阱：为什么默认模板可能拖慢你

向导最后一步，“Add sample code”复选框默认勾选。它会为你生成一个App.java和pom.xml（Maven）或build.gradle（Gradle），看起来很贴心。但这个“贴心”常是效率杀手。

问题在于：sample code基于Maven Archetype（原型）生成，而Archetype版本与你选的JDK/构建工具未必匹配。比如你选JDK 17 + Maven，IDEA可能调用maven-archetype-quickstart1.4版本，它生成的pom.xml里maven-compiler-plugin版本是3.8.1，而该插件在JDK 17下需升级到3.11.0才能支持--enable-preview参数。结果你一写record，IDEA就报“Unsupported target release 17”。

更隐蔽的问题是依赖污染。quickstart原型默认加了junit:junit:4.13.2，而现代项目该用JUnit 5（org.junit.jupiter:junit-jupiter:5.10.0）。如果你没手动删掉旧依赖，mvn test会同时加载JUnit 4和5的Runner，导致@Test注解被两个框架争抢，测试结果不可预测。

我的做法是：永远取消勾选“Add sample code”。然后手动创建最简结构：

• Maven项目：只保留pom.xml，内容精简到5行——<groupId>、<artifactId>、<version>、<packaging>jar</packaging>、<modelVersion>4.0.0</modelVersion>；
• Gradle项目：只保留build.gradle，内容就一行plugins { id 'java' }；
• 再手动建src/main/java目录，写第一个HelloWorld.java。

这样做的好处：

• 避免原型带来的版本错配；
• 强迫你理解每个XML/DSL元素的作用；
• 后续添加依赖时，你能清晰看到pom.xml如何增长，而不是面对一个堆砌了20个插件的“样板间”。

4. 项目结构落地：从向导结束到真正可编码的临门一脚

4.1 Project Structure里的三重校验：为什么向导完成≠项目可用

点击“Finish”后，IDEA会生成项目文件夹，但此时项目还处于“半激活”状态。必须进入File > Project Structure（快捷键Ctrl+Alt+Shift+S）做三重校验，否则后续编码必出问题。

第一重：Project Settings → Project

• Project SDK：确认与向导中选择的JDK一致；
• Project language level：确认与JDK主版本匹配（如JDK 17 → 17）；
• Project compiler output：这是编译后的.class文件存放路径，默认out。注意：Maven项目通常用target/classes，Gradle用build/classes，但IDEA的编译器输出路径是独立的。如果这里设成target/classes，而Maven又设<outputDirectory>target/classes</outputDirectory>，会导致重复编译——IDEA编译一次，Maven再编译一次，浪费30%时间。

第二重：Project Settings → Modules

• Sources标签页：确认src/main/java被标记为Sources（蓝色图标），src/main/resources为Resources（绿色图标），src/test/java为Tests（红色图标）。如果src/main/java没被识别，右键目录→Mark Directory as → Sources Root；
• Dependencies标签页：检查是否有<Module source>（本模块源码）、<JDK>（JDK库）、<Maven>（Maven依赖）三项。缺任何一项，代码补全和编译都会失效。

第三重：Platform Settings → SDKs

• 这里列出所有已配置的JDK。重点看Classpath和Sourcepath：
  • Classpath应包含jre/lib/rt.jar（JDK 8）或jmods/java.base.jmod（JDK 9+）；
  • Sourcepath应指向src目录（如C:\Program Files\Java\jdk-17.0.2\lib\src.zip）。如果Sourcepath为空，你按住Ctrl点String类会跳转到反编译的.class，而非原始Java源码——这对阅读JDK源码、调试ArrayList扩容逻辑是致命障碍。

我见过最离谱的案例：一个开发者向导选了JDK 17，但Project Structure > SDKs里该JDK的Sourcepath指向的是JDK 8的src.zip。结果他写List.of(1,2,3)时，IDEA提示“Cannot resolve method 'of' in List”，因为JDK 8的List接口根本没有of静态工厂方法——IDEA的代码分析引擎读的是JDK 8的源码，而非JDK 17的API。

4.2 目录结构的手动修正：当IDEA的自动识别失灵时

即使做完上述校验，仍可能遇到目录识别失败。常见于两种情况：

• 从Git克隆已有项目，但.idea文件夹被.gitignore过滤掉了；
• 用命令行mvn archetype:generate创建项目，再用IDEAOpen而非Import Project打开。

此时IDEA不会自动识别Maven/Gradle结构，你需要手动干预：

对于Maven项目：

1. 右键项目根目录→Add Framework Support→勾选Maven；
2. IDEA会扫描pom.xml，自动生成.idea/modules.xml和*.iml文件；
3. 如果src/main/java仍没变蓝，右键该目录→Mark Directory as → Sources Root；
4. 关键一步：在pom.xml里右键→Reload project，强制IDEA重新解析依赖。

对于Gradle项目：

1. 右键build.gradle→Import Gradle project；
2. 在弹窗里勾选Use default gradle wrapper和Auto-import；
3. 等待IDEA下载Gradle分发包并解析build.gradle；
4. 如果src/main/java未识别，同样右键→Mark Directory as → Sources Root。

注意：不要手动修改.iml文件！它是IDEA的内部元数据，格式极其脆弱。我曾因手改<sourceFolder url="file://$MODULE_DIR$/src" isTestSource="false" />里的url路径，导致整个模块无法加载，最终只能删掉.idea重来。一切目录标记操作，必须通过IDEA右键菜单完成。

4.3 第一个可运行的HelloWorld：验证闭环的黄金三步

向导完成后，别急着写业务代码。先用一个最简HelloWorld验证整个链条是否打通：

1. 创建文件：在src/main/java下新建包com.example.demo，再建类App.java；
2. 写代码：

package com.example.demo; public class App { public static void main(String[] args) { System.out.println("Hello, IntelliJ IDEA Java Project!"); } }

3. 运行验证：
   • 右键App.java→Run 'App.main()'；
   • 观察控制台输出是否为Hello, IntelliJ IDEA Java Project!；
   • 查看out/production/YourProjectName/com/example/demo/App.class是否存在（Maven项目看target/classes/com/example/demo/App.class）。

这三步看似简单，却串联了：

• JDK编译器（javac）能否正确解析语法；
• IDEA的类路径（Classpath）是否包含当前模块输出目录；
• 运行时JVM能否加载App类并执行main方法。

如果失败，按此顺序排查：

• 控制台报Error: Could not find or load main class App→ 检查Run Configuration里的Main class是否为com.example.demo.App，而非App；
• 报Exception in thread "main" java.lang.NoClassDefFoundError: com/example/demo/App→ 检查Project Structure > Modules > Dependencies里是否有<Module source>，且src/main/java被标记为Sources Root；
• 报java: cannot access com.example.demo.App→ 检查Project Structure > Project > Project compiler output路径是否可写，磁盘空间是否充足。

5. 常见故障全景排查：从“找不到JDK”到“模块循环依赖”

5.1 “No JDK specified for the project”：不是没装JDK，而是没告诉IDEA

这是New Project后最常弹出的警告。很多人以为是JDK没装，狂点“Download JDK”，结果下载完还是报错。真相是：IDEA没把JDK关联到当前项目。

解决路径分三步：

1. File > Project Structure > Project，在Project SDK下拉框里点New... > JDK；
2. 浏览到你JDK的安装根目录（如C:\Program Files\Java\jdk-17.0.2），不是bin目录，也不是jre目录，是包含lib、bin、jmods的父目录；
3. 点OK后，IDEA会自动填充JDK version和JDK home path，此时再点Apply。

如果步骤2里找不到JDK目录，说明你没正确安装JDK。验证方法：在命令行执行where java（Windows）或which java（Mac/Linux），得到路径后，往上退两级就是JDK根目录。例如where java返回C:\Program Files\Java\jdk-17.0.2\bin\java.exe，那么JDK根目录就是C:\Program Files\Java\jdk-17.0.2。

提示：不要用JRE路径！JRE只有运行时环境，没有javac编译器，IDEA会提示“JDK is required for compilation”。

5.2 “Cannot resolve symbol ‘xxx’”：90%源于源码根目录未标记

当你写import java.util.ArrayList;，IDEA却标红ArrayList，提示“Cannot resolve symbol ‘ArrayList’”，这不是JDK坏了，而是IDEA没把JDK的源码加入索引。

解决方案：

1. File > Project Structure > SDKs，选中你的JDK；
2. 在右侧Sourcepath列表里，点击+号；
3. 浏览到JDK安装目录下的lib/src.zip（JDK 8）或lib/src.zip（JDK 9+，部分发行版叫src.zip）；
4. 点OK，等待IDEA重新索引（右下角显示“Indexing…”）。

如果src.zip不存在（如某些精简版JDK），去对应发行版官网下载源码包。例如Temurin JDK 17的源码包在https://github.com/adoptium/temurin17-binaries/releases里，文件名类似OpenJDK17U-srce.zip。

5.3 Maven依赖不生效：不是网络问题，而是IDEA没刷新

写完pom.xml加了<dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.13.2</version></dependency>，但import org.junit.Test;依然标红。这不是Maven没下载jar，而是IDEA的依赖索引没更新。

强制刷新三步：

1. 右键pom.xml→Maven > Reload project；
2. 等待右下角“Maven projects need to be imported”提示消失；
3. 如果还不行，File > Invalidate Caches and Restart > Invalidate and Restart。

为什么需要手动刷新？因为IDEA的Maven插件是独立进程，它监听pom.xml变化，但有时监听失效。Reload project会杀死旧进程，启动新进程重新解析整个pom.xml树。

5.4 模块循环依赖：Gradle里藏得最深的“幽灵错误”

Gradle项目里，你可能遇到Circular dependency between projects错误，但build.gradle里明明没写循环引用。根源在于：Gradle的implementation project(':module-b')隐式包含了compileOnly传递性。

比如：

• module-a的build.gradle里写implementation project(':module-b')；
• module-b的build.gradle里写implementation project(':module-c')；
• module-c的build.gradle里写implementation project(':module-a')；

表面看是A→B→C→A，但Gradle在解析时会把implementation的传递依赖也纳入检查，导致循环判定。

解法只有两个：

• 重构依赖方向：让C依赖B，B依赖A，A不依赖C；
• 降级依赖作用域：把implementation project(':module-a')改成compileOnly project(':module-a')，这样C模块的编译期能看到A的API，但运行时不会传递A的jar包，打破循环链。

经验：在大型Gradle多模块项目里，我习惯用./gradlew dependencies --configuration compileClasspath命令查看编译期依赖树，比IDEA的图形化视图更精准定位循环点。

6. 超越向导：让项目从“能跑”到“好维护”的五个加固动作

6.1 配置.editorconfig：统一团队代码风格的第一道防线

向导生成的项目没有代码风格约束。你写if (x > 0) {，同事写if(x>0){，Git Diff里全是格式噪音。.editorconfig文件能强制IDEA遵守统一规范。

在项目根目录新建.editorconfig：

root = true [*] charset = utf-8 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true [*.java] indent_style = space indent_size = 4 continuation_indent_size = 4 tab_width = 4

然后安装IDEA的EditorConfig插件（Settings > Plugins搜索“EditorConfig”）。重启IDEA后，所有Java文件保存时会自动格式化为4空格缩进、LF换行符。这比每次Ctrl+Alt+L手动格式化更可靠，且能同步到VS Code、Sublime等编辑器。

6.2 初始化Git忽略文件：避免把IDEA私有配置推到远程

.gitignore里必须包含：

# IntelliJ IDEA .idea/ *.iml out/ target/ build/

特别注意.idea目录——它存着每个人的本地配置：JDK路径、Maven settings.xml位置、Run Configuration。如果把它提交到Git，团队里有人用Mac，有人用Windows，路径分隔符（/vs\）会导致.idea/workspace.xml冲突，合并时可能丢失调试断点。

6.3 添加README.md：用三句话说清项目是什么

很多项目README写满技术栈介绍，却没说清“这项目到底干啥”。我的模板：

# demo-project 一个演示IntelliJ IDEA Java项目创建流程的最小可行示例。 ## 快速启动 1. `git clone https://github.com/yourname/demo-project.git` 2. 用IntelliJ IDEA打开项目根目录 3. 运行`com.example.demo.App` ## 技术栈 - JDK 17 - Maven 3.8.6 - Java 17 Language Level

6.4 配置Maven镜像：让依赖下载从“龟速”变“秒级”

国内访问Maven Central常超时。在~/.m2/settings.xml里加镜像配置：

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

然后在IDEA的Settings > Build, Execution, Deployment > Build Tools > Maven里，把User settings file指向这个settings.xml，Local repository设为~/.m2/repository。

6.5 创建标准化Run Configuration：告别每次都要右键Run

Run > Edit Configurations > + > Application，填：

• Name:App
• Main class:com.example.demo.App
• Working directory:$ProjectFileDir$
• Use classpath of module:demo-project（你的模块名）

点OK后，顶部工具栏会出现App下拉框，以后一键运行，不用再右键找文件。

我在实际使用中发现，新手最容易忽略的是“Working directory”设为$ProjectFileDir$。如果设成$ModuleFileDir$，运行时System.getProperty("user.dir")返回的是模块目录，而读取src/main/resources/config.properties时路径就错了——因为资源文件在模块根目录下，而非模块子目录。这个细节，决定了你的配置文件是“总能找到”，还是“偶尔失踪”。