是纯元数据字段，仅在 mvn site 生成的项目站点中显示，不影响构建、部署、签名或审核；IDE、CI、SonarQube 等均不识别，实际责任人应通过 、CODEOWNERS、mailmap 等机制落实。
为什么 <developers></developers> 在 pom.xml 里基本没用
它不会被 Maven 构建过程读取，也不会影响任何生命周期行为（比如打包、部署、依赖解析）。Maven 官方文档明确说这是「纯元数据字段」，只在生成项目站点（mvn site）时可能出现在报告页里——而绝大多数项目根本不用这个功能。
常见错误现象：<developers></developers> 写得再全，IDE 不识别、CI 日志不显示、JAR 包里不嵌入、SonarQube 不抓取。有人以为它能替代 Git 提交作者或 Jira 责任人，结果发现完全对不上。
- 它不参与 GPG 签名验证，
mvn gpg:sign完全无视这个块 - 发布到 Maven Central 时，
ossrh审核也不看它；实际责任人靠的是<scm></scm>和 Nexus 登录账号 - 如果想让团队成员在 IDE 中快速看到维护者，不如把联系人写进
README.md或CONTRIBUTING.md
<developers></developers> 的唯一真实使用场景
只有当你主动运行 mvn site 并启用 maven-project-info-reports-plugin（默认不启用），且部署了生成的 HTML 站点，访问 project-info.html 页面时才可能看到「Project Team」一栏列出的人名和邮箱。
但要注意：这个页面是静态生成的，不会自动同步 Git 提交记录；邮箱地址明文暴露在 HTML 源码里，容易被爬虫收集；而且现代团队基本用 GitHub Teams、Slack 频道或内部 Wiki 维护人员映射，没人翻这个页面。
- 如果你真要生成站点，记得检查插件版本 —— 3.4.0+ 才支持
<developers></developers>渲染，老版本直接忽略 - 邮箱字段填错格式（比如漏掉
@）会导致mvn site报Malformed email address错误，但构建仍会成功 - 多个
<developer></developer>元素按 XML 顺序排列，无排序逻辑，也不能标「primary maintainer」
替代方案：真正起作用的开发者信息落点
想让机器或人快速定位负责人，优先用有实际触发点的地方：
-
<scm></scm>块里的<url></url>（如https://github.com/xxx/yyy）—— CI 工具、依赖扫描器、IDE 插件都认这个 -
.mailmap文件（Git 仓库根目录）—— 统一不同 commit 邮箱，比 pom 里硬编码更可靠 -
CODEOWNERS（GitHub）或OWNERS（GitLab）—— PR 自动 @ 相关人，这才是真联动 - CI 配置里显式声明
MAINTAINER_EMAIL环境变量 —— 构建失败通知能精准发到人
如果非得保留 <developers></developers>，怎么写才少出错
不是推荐你写，而是万一 legacy 项目里已有，别让它拖累构建或误导新人。
- 只填真实活跃的当前维护者，别把离职同事留在里面（容易造成误发邮件）
-
<email></email>必须是可收信的地址，且避免用个人域名邮箱（公司域名更稳定） - 不要填
<organizationurl></organizationurl>—— 这个字段在 maven-site-plugin 3.12.0 后已废弃，留着会触发警告 - 若用
mvn release:prepare，确保<developer></developer>里的<id></id>和 Nexus 用户名一致（极少数定制流程需要）
最常被忽略的一点：这个块不支持表达「角色变更」—— 比如某人从 contributor 升为 maintainer，XML 里只能删掉重写，没法加时间戳或状态标记。真要追踪权责变化，Git Blame 和 PR 记录比它准得多。
