Maven继承父POM：哪些元素合并/覆写？是否有对应清单？

嘿，这个问题问到点子上了！Maven在处理父POM继承时，确实有一套明确的规则来区分哪些元素会合并、哪些会被覆写，我给你梳理清楚：

这类元素会把父POM的配置和子POM的配置整合到一起，不会直接覆盖：

• dependencies：子POM的依赖会和父POM的依赖合并。如果父子POM有同一个依赖，子POM指定的版本会优先于父POM的；要是子POM没指定版本，就继承父POM的版本（如果父POM在dependencyManagement里管控了版本，那子POM可以直接引用无需写版本）。
• build/plugins：插件配置会合并。子POM可以新增插件，也可以对父POM已有的插件补充配置（比如添加新的执行目标、修改参数）。
• build/pluginManagement/plugins：和插件配置类似，子POM可以继承父POM的插件管理规则，同时补充自己的插件管理项。
• repositories & pluginRepositories：仓库地址会合并，子POM新增的仓库会和父POM的仓库一起生效，用于依赖和插件的拉取。
• profiles：父POM的Profile会和子POM的Profile合并。子POM可以新增Profile，也可以修改父POM中已有Profile的配置（比如激活条件、属性）。

这类元素只要子POM明确指定了值，就会完全替换父POM的对应配置：

• groupId、artifactId、version：项目坐标的核心三元素，子POM如果指定了就会直接覆盖父POM的（不过通常groupId会继承父POM，version也可以继承，但如果子POM自己写了就用子的）。
• packaging：打包类型（比如jar、war、pom），子POM指定的类型会完全覆盖父POM的设置。
• name、description、url：这些项目描述类的元数据，子POM写了就用子的，没写才会继承父POM的内容。
• properties：同名属性会直接覆盖——比如父POM定义了<maven.compiler.source>1.8</maven.compiler.source>，子POM如果写了<maven.compiler.source>11</maven.compiler.source>，就会用11。
• build/finalName：构建后的最终文件名，子POM指定的值会完全替换父POM的设置。
• distributionManagement：发布到仓库的配置（比如私服地址、快照仓库），子POM的配置会直接覆盖父POM的，不会合并。

有些元素的合并有特殊逻辑：比如dependencies里的依赖排除（exclusions），子POM可以给父POM的依赖添加新的排除项；而plugins里如果子POM完全重写了某个插件的<executions>块，那会覆盖父POM里该插件的执行配置，而不是合并。

内容的提问来源于stack exchange，提问作者Stephen