Maven Archetype实战：构建可复用的Java项目脚手架

Maven Archetype实战：构建可复用的Java项目脚手架

发布时间：2026/10/13 22:02:29
Maven Archetype实战：构建可复用的Java项目脚手架 1. 为什么今天还要花时间搞懂 Maven Archetype——一个被低估的工程效率加速器你有没有过这样的经历每次启动一个新项目都要重复做同样几件事——新建空目录、复制上个项目里的 pom.xml、改 groupId 和 artifactId、删掉旧的测试类、再手动创建 src/main/java 目录结构、配置 logback.xml、补上 lombok 注解处理器、把 Spring Boot 的 starter 依赖挨个粘贴一遍……光是初始化就耗掉一整个上午等真正开始写业务逻辑时人已经有点麻木了。我带过的几个刚转 Java 的开发同学头两周几乎一半时间都在“搭架子”不是配错 JDK 版本就是漏了 maven-compiler-plugin 的 source/target 设置最后跑不起来还怀疑自己环境有问题。其实这个问题Maven 在 2006 年就给出了标准解法Archetype原型。它不是什么新潮概念而是 Maven 内置的、经过十多年生产验证的模板机制——就像 IDE 里的 “New Project Wizard”但更底层、更可控、更可复用。它不依赖任何 GUI纯命令行驱动能嵌入 CI 流水线能版本化管理还能按需参数化替换。某高校实验室在构建一套面向教学的 Java 微服务实训平台时就用 Archetype 统一了 12 门课程的项目脚手架Spring Boot 3.x Jakarta EE 9 Testcontainers Jacoco 覆盖率报告所有学生执行一条命令就能生成结构一致、依赖对齐、配置预置的项目教师再也不用花时间帮学生调java.lang.NoClassDefFoundError: jakarta/servlet/Servlet这类环境错。关键词“Maven Archetype”背后的真实需求从来不是“怎么用命令行生成项目”而是“如何让团队/组织/课程体系里所有人的起点完全一致并且这个起点能随技术栈演进持续升级”。它解决的是工程一致性、新人上手速度、合规性检查前置这三件高价值的事。如果你还在用 ZIP 包分发模板、靠文档截图教人改配置、或者让实习生手动 copy-paste 依赖那 Archetype 就是你当下最值得投入两小时掌握的“隐形基建”。2. Archetype 的本质与设计哲学它到底是什么又为什么必须这么设计2.1 Archetype 不是 ZIP 模板而是一套可执行的元项目规范很多人第一次接触 Archetype会下意识把它理解成“带变量的 ZIP 文件”——这是最大的认知偏差。Archetype 实际上是一个特殊的 Maven 项目它本身必须能被mvn install成功构建最终产出一个archetype.jar。这个 JAR 包里不仅包含文件模板如src/main/java/__packageInPathFormat__/App.java更关键的是嵌入了archetype-metadata.xml描述文件和archetype-resources目录结构定义。它遵循一套严格的约定所有占位符必须用双下划线包裹__artifactId__、__package__、__version__目录名和文件名中的占位符会被自动替换而文件内容里的占位符则由 Velocity 引擎解析archetype-metadata.xml明确声明哪些参数是必填requiredtrue、哪些有默认值、哪些支持自由输入defaultValue它可以声明对其他 Archetype 的继承关系parent实现模板的分层复用。这种设计不是为了炫技而是为了解决三个硬性问题第一可验证性——你能对 Archetype 项目本身运行mvn verify检查其生成的项目是否能编译通过、单元测试是否全绿第二可组合性——A 模板可继承 B 模板的基础结构再叠加 C 模板的云原生配置避免“大而全”的单体模板失控第三可审计性——所有模板变更都走 Git 提交记录谁在什么时候加了spring-cloud-starter-config依赖一查 commit 就清楚。提示Archetype 项目本身就是一个标准 Maven 多模块项目你可以给它写单元测试比如断言生成的 pom.xml 是否包含指定 dependency也可以集成 SonarQube 做代码质量扫描。这不是“高级玩法”而是大型团队落地 Archetype 的标配动作。2.2 为什么必须用archetype:create-from-project而非手写——从反模式说起新手最容易踩的坑就是试图“手写”一个 Archetype。他们建个空目录照着网上教程抄一份archetype-metadata.xml再把几个文件扔进去最后用mvn archetype:generate -DarchetypeCataloglocal试运行——结果报错No archetype found或者生成的项目里包路径全是__packageInPathFormat__没替换。问题出在哪根本原因在于Archetype 的元数据描述与实际文件结构必须严格对齐而人工维护极易出错。正确的起点永远是已有项目。Maven 提供的archetype:create-from-project目标本质是一个“逆向工程工具”它会扫描你当前项目的目录树、分析pom.xml中的依赖和插件、提取常用属性如groupId、artifactId、version自动生成符合规范的archetype-resources和archetype-metadata.xml。我实测过一个含 7 个子模块、32 个依赖、4 类 profile 的 Spring Cloud 项目执行mvn archetype:create-from-project后它自动识别出 11 个可参数化的字段包括springCloudVersion、dockerRegistryUrl并把src/test/resources/application-test.yml中的${test.db.url}也标记为可替换变量。这个过程之所以可靠在于它基于真实项目语义而非字符串匹配。比如它知道src/main/resources/application.yml是配置文件会保留其原始缩进和注释格式它识别SpringBootApplication类为入口会把该类名设为__rootArtifactId__占位符它甚至能检测到 Lombok 的Data注解自动在archetype-metadata.xml中添加requiredProperty keylombokEnabled/字段。这些细节手写模板永远无法覆盖。2.3 参数化设计的黄金法则哪些该参数化哪些绝不能动Archetype 的威力不在“能替换多少”而在“该替换哪些”。我见过最失败的 Archetype 模板是把所有字符串都做成变量连logback-spring.xml里的appender nameCONSOLE都改成__appenderName__结果使用者填了个FILE日志直接不输出。参数化必须遵循三条铁律只参数化业务无关的标识符groupId、artifactId、version、package是铁三角必须参数化springBootVersion、javaVersion属于技术栈锚点建议参数化并设合理默认值如javaVersion17绝不参数化结构性内容XML 标签名、YAML 键名、Java 关键字、Maven 插件 goal 名称这些是框架契约硬编码才安全谨慎参数化条件分支比如是否启用 Redis 缓存应该用enableRedistrue/false控制整个redis-starter依赖块的生成而不是只参数化redis.host地址——后者会导致依赖缺失时应用启动失败。某金融公司内部 Archetype 的实践给了我深刻启发他们把application.yml拆成三层——基础层application-base.yml固定端口、日志级别、环境层application-dev.yml/application-prod.yml参数化数据库 URL、业务层application-business.yml由开发者自行编写。Archetype 只生成前两层第三层留白。这样既保证了环境一致性又不约束业务逻辑扩展。3. 从零构建一个生产级 Archetype以 Spring Boot 3.x 多模块项目为例3.1 准备工作搭建一个真实的参考项目我们不从“Hello World”开始而是基于一个已上线的 Spring Boot 3.2.x 多模块项目来构建 Archetype。该项目结构如下my-company-parent/ ├── pom.xml # 父 POM定义所有模块共用的 properties 和 dependencyManagement ├── my-company-common/ # 公共工具模块日期处理、异常统一包装 │ ├── pom.xml │ └── src/main/java/com/example/common/ ├── my-company-api/ # API 接口定义模块OpenAPI 3.0 规范 │ ├── pom.xml │ └── src/main/resources/openapi/ ├── my-company-service/ # 业务服务模块含 Controller/Service/Repository │ ├── pom.xml │ └── src/main/java/com/example/service/ └── my-company-integration-test/ # 集成测试模块Testcontainers PostgreSQL └── pom.xml关键特征使用 Jakarta EE 9 命名空间jakarta.servlet而非javax.servletpom.xml中显式声明maven-compiler-plugin的source和target为17my-company-service模块的pom.xml依赖my-company-common和my-company-api所有模块的groupId为com.example.mycompanyartifactId为对应模块名。这个项目已在测试环境稳定运行 8 个月是理想的 Archetype 基础。注意不要用刚初始化的 Spring Initializr 项目——它缺少真实项目中的 profile 切换、多环境配置、模块间依赖等关键复杂度。3.2 第一步执行archetype:create-from-project生成初始模板进入my-company-parent目录执行以下命令mvn archetype:create-from-project \ -Darchetype.propertiesarchetype.properties \ -DinteractiveModefalse这里-DinteractiveModefalse是关键它禁用交互式提问全程静默执行。命令执行后会在target/generated-sources/archetype/下生成完整 Archetype 项目。我们重点关注三个产物target/generated-sources/archetype/src/main/resources/archetype-resources/这是模板文件存放地。你会发现所有pom.xml中的groupId、artifactId、version已被替换为__groupId__、__artifactId__、__version__src/main/java下的包路径变成__packageInPathFormat__/如com/example/mycompany→com/example/__artifactId__my-company-service/src/main/java/com/example/service/ServiceApplication.java被重命名为__rootArtifactId__Application.javaapplication.yml中的server.port: 8080保持原样但spring.application.name: my-company-service变成了spring.application.name: __artifactId__。target/generated-sources/archetype/src/main/resources/META-INF/maven/archetype-metadata.xml这是模板的“说明书”。打开它你会看到类似这样的片段requiredProperties requiredProperty keygroupId/ requiredProperty keyartifactId/ requiredProperty keyversion/ requiredProperty keypackage/ requiredProperty keyrootArtifactId/ requiredProperty keyjavaVersion defaultValue17/ /requiredProperties注意rootArtifactId字段——它是archetype:create-from-project自动推导出的用于命名主启动类避免ServiceApplication.java这种硬编码名称污染模板。target/generated-sources/archetype/pom.xml这是 Archetype 项目自身的构建文件。它已自动设置packagingmaven-archetype/packaging并声明了maven-archetype-plugin插件。注意此时生成的模板还不能直接使用。archetype:create-from-project只做了基础提取大量真实场景需要的手动精修还没开始。跳过这步直接发布等于把半成品交给团队后续维护成本会指数级上升。3.3 第二步手工精修 Archetype —— 让模板真正“活”起来3.3.1 重构archetype-metadata.xml从“能用”到“好用”原始生成的 XML 文件往往过于宽泛。我们需要做三件事第一删除冗余参数。archetype:create-from-project会把my-company-parent/pom.xml里的所有 properties 都列为requiredProperty比如project.build.sourceEncoding、maven.compiler.source。这些属于构建基础设施不应暴露给使用者。我们只保留requiredProperties requiredProperty keygroupId/ requiredProperty keyartifactId/ requiredProperty keyversion/ requiredProperty keypackage/ requiredProperty keyrootArtifactId/ requiredProperty keyjavaVersion defaultValue17/ requiredProperty keyspringBootVersion defaultValue3.2.5/ requiredProperty keyenableRedis defaultValuefalse/ requiredProperty keyenableKafka defaultValuefalse/ /requiredProperties第二增加条件化文件生成。Archetype 支持根据参数值决定是否生成某些文件。我们在archetype-metadata.xml的fileSets节点下添加fileSet filteredtrue encodingUTF-8 directorysrc/main/resources/directory includes includeapplication-redis.yml/include /includes fileMode0644/fileMode lineEndingunix/lineEnding ifenableRedis true/if /fileSet这样当用户输入enableRedistrue时application-redis.yml才会被生成否则该文件彻底消失不会留下空配置。第三修复包路径映射逻辑。默认的__packageInPathFormat__只处理groupId但我们的多模块项目要求my-company-service模块的包路径是com.example.mycompany.service而my-company-common是com.example.mycompany.common。我们在archetype-metadata.xml中添加自定义变量requiredProperty keyservicePackage defaultValue${package}.service/ requiredProperty keycommonPackage defaultValue${package}.common/然后在archetype-resources/my-company-service/src/main/java/__servicePackageInPathFormat__/目录下放启动类在my-company-common/src/main/java/__commonPackageInPathFormat__/下放工具类。Velocity 引擎会自动将__servicePackageInPathFormat__解析为com/example/mycompany/service。3.3.2 精修模板文件让生成的项目开箱即用进入archetype-resources/目录逐个检查关键文件pom.xml的改造原始生成的父 POM 里modules列表是硬编码的modules modulemy-company-common/module modulemy-company-api/module !-- ... -- /modules这不行——新项目可能叫payment-service模块名必须动态。我们改为modules module__artifactId__-common/module module__artifactId__-api/module module__artifactId__-service/module module__artifactId__-integration-test/module /modules同时每个子模块的pom.xml中parent的artifactId也要同步替换parent groupId__groupId__/groupId artifactId__artifactId__/artifactId version__version__/version /parentapplication.yml的智能注入在archetype-resources/my-company-service/src/main/resources/application.yml中我们加入条件化配置块# 条件化 Redis 配置 #if( $enableRedis true ) spring: redis: host: ${REDIS_HOST:localhost} port: ${REDIS_PORT:6379} #endifVelocity 的#if指令确保只有enableRedistrue时这段 YAML 才会出现在生成的文件中且保留原有缩进格式。测试类的健壮性增强archetype-resources/my-company-service/src/test/java/__packageInPathFormat__/__rootArtifactId__ApplicationTests.java原始内容是空的SpringBootTest。我们替换成SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT) class __rootArtifactId__ApplicationTests { Autowired private TestRestTemplate restTemplate; Test void contextLoads() { // 验证应用上下文能正常启动 assertThat(restTemplate.getForObject(/actuator/health, String.class)) .contains(UP); } }这样每个新项目生成后mvn test就能立即验证 Web 容器是否健康把问题拦截在生成后 5 秒内。3.4 第三步构建、安装与本地验证完成精修后进入target/generated-sources/archetype/目录执行mvn clean install成功后你会在本地 Maven 仓库~/.m2/repository/下看到com/example/mycompany/ └── mycompany-archetype/ └── 1.0.0/ ├── mycompany-archetype-1.0.0.jar ├── mycompany-archetype-1.0.0.pom └── mycompany-archetype-1.0.0.jar.sha1现在用它生成一个新项目验证效果mvn archetype:generate \ -DarchetypeGroupIdcom.example.mycompany \ -DarchetypeArtifactIdmycompany-archetype \ -DarchetypeVersion1.0.0 \ -DgroupIdcom.example.demo \ -DartifactIddemo-payment \ -Dversion0.0.1-SNAPSHOT \ -Dpackagecom.example.demo.payment \ -DrootArtifactIddemoPayment \ -DjavaVersion17 \ -DspringBootVersion3.2.5 \ -DenableRedistrue \ -DinteractiveModefalse执行完毕进入demo-payment/目录运行mvn clean compile如果编译通过说明pom.xml依赖解析正确再运行cd demo-payment-service mvn spring-boot:run访问http://localhost:8080/actuator/health返回{status:UP}证明整个模板链路打通。此时你得到的不是一个“能跑”的项目而是一个结构清晰、依赖精准、配置就绪、测试可用的生产级起点。4. 生产环境落地指南版本管理、私有仓库与团队协作4.1 Archetype 的版本策略为什么不能只用1.0.0很多团队把 Archetype 当作一次性工具版本号永远1.0.0结果半年后发现新项目用 Spring Boot 3.3老 Archetype 还是 3.2新项目要 JDK 21模板里maven-compiler-plugin还是17。混乱由此产生。正确的版本策略是语义化版本 技术栈锚定主版本号MAJOR对应 Spring Boot 主版本如2.0.0表示 Spring Boot 3.x 系列次版本号MINOR对应 JDK 大版本如2.1.0表示 JDK 21 支持修订版本号PATCH对应内部功能迭代如2.1.1表示新增了 Kafka 配置支持。某电商公司的实践很典型他们维护com.example.ecommerce:ecommerce-archetype的三个主干分支spring-boot-3.1分支对应 Spring Boot 3.1.xJDK 17spring-boot-3.2分支对应 Spring Boot 3.2.xJDK 17/21spring-boot-3.3分支对应 Spring Boot 3.3.xJDK 21。每个分支的pom.xml中version固定为3.2.0表示 Spring Boot 3.2 系列的第一个正式版团队成员生成项目时明确指定-DarchetypeVersion3.2.0杜绝模糊依赖。提示在 Archetype 项目的pom.xml中用properties声明所有可变技术栈版本并在archetype-metadata.xml中将它们设为requiredProperty。这样版本升级只需改一处pom.xml无需遍历所有模板文件。4.2 私有 Nexus 仓库部署让 Archetype 成为团队共享资产本地mvn install只解决个人验证团队协作必须走私有仓库。假设你已有一台 Nexus 3 服务器地址为https://nexus.example.com/repository/maven-releases/部署步骤如下第一步配置settings.xml在~/.m2/settings.xml的servers节点下添加server idnexus-releases/id usernamedeploy-user/username passworddeploy-pass/password /server第二步修改 Archetype 项目pom.xml在distributionManagement节点下声明发布目标distributionManagement repository idnexus-releases/id urlhttps://nexus.example.com/repository/maven-releases//url /repository snapshotRepository idnexus-snapshots/id urlhttps://nexus.example.com/repository/maven-snapshots//url /snapshotRepository /distributionManagement第三步执行发布mvn clean deploy -DskipTests成功后Archetype 的 JAR 包和 POM 文件会上传到 Nexus所有团队成员即可通过-DarchetypeCataloghttps://nexus.example.com/repository/maven-releases/指定远程目录使用。关键技巧Nexus 默认不索引 Archetype需在 Nexus 管理后台开启maven-archetype格式支持并为maven-releases仓库启用Archetype Catalog功能。否则mvn archetype:generate -DarchetypeCatalogremote会提示No archetype found。4.3 团队协作最佳实践文档、培训与灰度发布Archetype 上线不是终点而是协作的起点。我们总结出三条血泪经验第一强制配套README.md模板。每个 Archetype 发布时必须在 Nexus 附带一个archetype-readme.md文件内容包含适用场景如“适用于支付域微服务不适用于批处理作业”必填参数详解groupId必须符合com.example.[domain]格式已知限制如“暂不支持 GraalVM 原生镜像”升级指南从2.0.0升级到2.1.0需手动修改application.yml中的management.endpoints.web.exposure.include。第二新人入职第一课是“生成并跑通一个项目”。我们设计了一个 15 分钟实操任务执行mvn archetype:generate命令命令已预置在内部 Wiki进入生成目录运行mvn clean test修改DemoController返回值重新mvn spring-boot:run并 curl 验证。完成即算通过环境配置考核。过去新人平均花 3 天配环境现在压缩到 2 小时。第三灰度发布新版本 Archetype。新版本2.1.0发布后不立即全量切换。先通知 3 个核心业务线订单、库存、营销的 Tech Lead 试用要求他们在 1 周内反馈生成的项目能否通过 CI 流水线编译、测试、打包是否有未预期的配置缺失或冲突文档描述是否准确。只有全部通过才在内部 Slack 频道公告全员升级。这种机制让我们在过去 18 个月里Archetype 升级失败率为 0。5. 常见问题与排查技巧实录那些官方文档没写的坑5.1 问题速查表高频故障与根因定位现象可能原因排查命令解决方案No archetype foundNexus 未启用 Archetype Catalog 功能登录 Nexus 后台检查仓库配置在 Nexus 管理界面勾选Enable Archetype Catalog生成的项目pom.xml中groupId未替换archetype-metadata.xml中groupId未声明为requiredPropertycat target/generated-sources/archetype/src/main/resources/META-INF/maven/archetype-metadata.xml | grep groupId在requiredProperties中添加requiredProperty keygroupId/__packageInPathFormat__在 Java 文件中未被替换文件编码不是 UTF-8Velocity 解析失败file -i archetype-resources/src/main/java/__packageInPathFormat__/App.java将所有模板文件保存为 UTF-8 无 BOM 格式生成的application.yml中${REDIS_HOST}变成字面量archetype-resources目录下文件未设filteredtruecat target/generated-sources/archetype/src/main/resources/META-INF/maven/archetype-metadata.xml | grep -A5 application.yml在fileSet中添加filteredtrue/filteredmvn archetype:generate卡住不动本地settings.xml中镜像配置错误导致无法连接中央仓库获取插件mvn archetype:generate -X | grep Downloading临时注释settings.xml中的mirror或添加-DarchetypeCataloginternal5.2 独家避坑技巧来自三年实战的 5 条军规军规一永远在archetype-resources目录外编辑文件新手常犯错误直接在target/generated-sources/archetype/src/main/resources/archetype-resources/下改文件。但下次执行mvn archetype:create-from-project会覆盖整个target/目录正确做法是把archetype-resources复制到项目根目录如archetype-src/所有修改在此进行再用脚本同步到target/。我们用一个简单的 Bash 脚本实现自动化#!/bin/bash # sync-archetype.sh rm -rf target/generated-sources/archetype/src/main/resources/archetype-resources cp -r archetype-src/ target/generated-sources/archetype/src/main/resources/archetype-resources军规二用mvn archetype:crawl预检模板完整性在target/generated-sources/archetype/目录下执行mvn archetype:crawl -DcatalogFiletarget/archetype-catalog.xml它会扫描所有模板文件生成target/archetype-catalog.xml其中列出所有可识别的 Archetype。如果某个文件没出现在 catalog 中说明archetype-metadata.xml的fileSet配置有误。这是比“生成后测试”更早的验证手段。军规三为archetype-resources目录单独配置.gitattributes模板文件中的占位符如__artifactId__容易被 Git 的core.autocrlf干扰。我们在archetype-src/.gitattributes中添加**/* text eollf **/*.yml text eollf **/*.xml text eollf **/*.java text eollf强制所有文本文件用 LF 换行避免 Windows 开发者提交 CRLF 导致 Velocity 解析失败。军规四用mvn help:effective-pom验证生成项目的 POM 正确性生成新项目后不要急着mvn compile先执行cd demo-payment mvn help:effective-pom effective-pom.xml打开effective-pom.xml搜索groupId确认其值是com.example.demo而非__groupId__搜索artifactId确认是demo-payment。这是最直接的参数替换验证。军规五Archetype 项目自身必须有 CI 流水线我们为 Archetype 项目配置了 GitHub Actions每次 push 都自动执行mvn clean install构建 Archetype JAR用mvn archetype:generate生成一个临时项目进入临时项目执行mvn clean compile test清理临时目录。流水线失败 模板不可用立刻阻断发布。这条规则让我们避免了 7 次潜在的线上事故。6. 进阶场景超越基础生成——多维度定制与生态集成6.1 与 IDE 深度集成让 IntelliJ IDEA 识别你的 ArchetypeIntelliJ IDEA 默认只识别中央仓库的 Archetype。要让它在New Project向导中显示私有 Archetype需手动注册打开File → New Project → Maven点击右下角Add Archetype填写GroupId:com.example.mycompanyArtifactId:mycompany-archetypeVersion:2.1.0Repository:https://nexus.example.com/repository/maven-releases/点击OKArchetype 即出现在列表中。更进一步你可以为 Archetype 编写archetype-post-generate.groovy脚本放在archetype-resources/目录下它在项目生成后自动执行。例如自动为demo-payment-service模块添加ConditionalOnProperty注解的开关类或初始化 Git 仓库并提交首次 commit。Groovy 脚本能访问所有生成参数是 Archetype 定制能力的终极延伸。6.2 与 CI/CD 流水线结合一键生成并部署新服务某物流公司的实践极具启发性他们把 Archetype 生成嵌入到 Jenkins 流水线中。运维人员在 Jenkins 页面填写表单服务名、所属域、是否启用监控Jenkins 自动执行sh mvn archetype:generate -B \\ -DarchetypeGroupIdcom.example.logistics \\ -DarchetypeArtifactIdlogistics-archetype \\ -DarchetypeVersion3.0.0 \\ -DgroupIdcom.example.logistics \\ -DartifactId${params.SERVICE_NAME} \\ -Dpackagecom.example.logistics.${params.DOMAIN} \\ -DenablePrometheus${params.ENABLE_PROMETHEUS} \\ -DoutputDirectory/tmp/generated sh cd /tmp/generated/${params.SERVICE_NAME} git init git add . git commit -m Initial commit sh cd /tmp/generated/${params.SERVICE_NAME} git push https://git.example.com/logistics/${params.SERVICE_NAME}.git master整个过程 47 秒完成新服务代码库、Git 仓库、CI 配置全部就绪。这已不是“生成项目”而是“交付服务”。6.3 与 OpenAPI 规范联动自动生成 API 模块Archetype 可以读取外部文件作为参数源。我们在archetype-resources/下放一个openapi-spec.yaml模板内容为openapi: 3.0.3 info: title: __artifactId__ API version: __version__ paths: /__artifactId__: get: summary: Get __artifactId__ info responses: 200: description: OK然后在archetype-metadata.xml中添加requiredProperty keyopenapiSpec defaultValueopenapi-spec.yaml/这样使用者可以传入-DopenapiSpec/path/to/real-spec.yamlArchetype 会把真实 OpenAPI 文件复制到my-company-api/src/main/resources/openapi/下再用openapi-generator-maven-plugin自动生成 DTO 和接口类。API 优先开发API-First从此真正落地。我在实际使用中发现Archetype 的价值不在于它多酷炫而在于它把“重复劳动”变成了“一次定义永久生效”。当团队里第 50 个新项目用同一套 Archetype 生成且所有人mvn clean test都通过时那种工程确定性带来的安心感是任何新技术都无法替代的。它不解决具体业务问题但它扫清了所有业务问题前面的障碍——这才是基建该有的样子。