Maven 3.10 找不到仓库中已有的包：检查前缀过滤

Maven 3.10.0 升级后，内部包解析失败，日志包含 ArtifactFilteredOutException 和 prefixes: Path ... NOT allowed from central。同一制品通过仓库的正常访问入口确实存在时，先检查远程仓库前缀过滤，别把这条错误直接当成 404 或版本号写错。

一种明确场景是：名为 central 的仓库实际指向 Artifactory 或 Nexus 聚合地址，其中既有公共 Central 代理，也有内部制品库；聚合地址却返回了某一个公共成员的 prefixes.txt。这份列表不包含内部路径，Maven 因而在下载前拒绝它们。

为什么升级后才暴露

Maven 3.10 使用的 Resolver 2.x 默认启用过滤，并会自动发现前缀文件。Maven 3.9 的 Resolver 1.x 默认不走相同的自动前缀发现路径，所以“旧版可下载”不证明聚合仓库发布的元数据正确。

核对失败日志中的仓库 ID、实际镜像地址及被拒绝的制品路径，再由有权限的仓库管理员检查聚合入口返回的前缀内容。HTTP 能下载制品，只证明该路径可访问；前缀文件仍可能不完整。反过来，某个前缀存在也不保证该前缀下每个版本都已发布。

Resolver 2.0.21 起会对每仓库的首次自动发现前缀拒绝做一次有界存在性验证；2.0.22 起，发现不一致时只放行已核实的那条路径。它不会逐项验证全部拒绝路径，也不会重新质疑用户手工提供的前缀文件。因此，不能承诺换到较新的 Resolver 就自动放行所有内部包。

临时调整要限定范围

长期处理是让聚合仓库提供覆盖实际内容的前缀，或停止从错误的成员透传这份文件。修复服务端前，可以按项目策略停用自动发现：

mvn -Daether.remoteRepositoryFilter.prefixes.resolvePrefixFiles=false validate

这条属性停止自动解析前缀文件，不等于关闭所有仓库过滤；已有手工前缀仍需单独检查。validate 只是示例目标，实际应保留原构建目标、settings、profile 和其他必要参数，构建仍可能执行项目插件并下载依赖。

若确定只需停用某个仓库的前缀过滤，可使用按仓库 ID 限定的设置。例如日志中的实际仓库 ID 确为 central 时：

mvn -Daether.remoteRepositoryFilter.prefixes.central=false validate

不要把所有仓库的过滤长期一并关闭。过滤还用于减少向不相关仓库泄露坐标，绕行应保留其他仓库的约束，并交由项目与仓库管理员共同确定期限。无需先删除整份 .m2/repository；清缓存不会补全服务端错误的前缀。

验收回到原失败的完整构建，确认内部包来自预期的聚合仓库、原坐标没有被改写，其他仓库过滤仍按配置生效。服务端元数据恢复后撤回临时属性，再检查同一路径，避免把绕行永久留在 CI。