Maven 的 SNAPSHOT 快照版本，本质上就是通过一个 -SNAPSHOT 后缀来标识的。它依赖远程仓库中的 maven-metadata.xml 文件，能够根据时间戳自动拉取最新的构建产物。这样一来，在开发阶段进行高频迭代就变得非常便捷。而 Release 版本，内容一旦发布就固定下来，不允许覆盖，生产环境必须使用这个版本。
想象一下，在团队协作中，你频繁修改模块，每修复一个 Bug 就得升级一次版本号，那该有多麻烦。SNAPSHOT 快照版本正是为了解决这个问题而生的：它能让依赖自动拉取最新代码，省去手动更新、版本号混乱的烦恼，构建失败的情况也因此大大减少。
为什么必须使用 -SNAPSHOT 后缀
在 pom.xml 的 1.0.0-SNAPSHOT，Maven 才会将其识别为快照版本。如果不加这个后缀，哪怕你在本地执行了十次 install，其他项目引用时，它只会锁定第一次下载的 jar 包，后续的所有变更都不会被感知。
这一步是关键的开关——没有 -SNAPSHOT，整个快照机制就彻底失效了。
注意，-SNAPSHOT 必须全部大写。写成 -snapshot 或 -SnapShot 都是无效的。
快照如何实现“自动更新”
Maven 并不是靠猜测，而是依赖远程仓库中的 maven-metadata.xml 文件来判断哪个快照是最新的。这个文件由 deploy 过程自动生成并上传，其中记录了所有带时间戳的构建版本，例如 1.0.0-20260804.152311-7.jar。
每次执行 mvn compile 或 mvn package 时，只要本地仓库中该快照的元数据过期了（默认是每 24 小时检查一次），Maven 就会重新请求远程仓库的 maven-metadata.xml，然后对比时间戳，自动下载编号最大的那个构建产物。
有两种方法可以控制这个检查频率：
- 方法一：强制立即检查最新快照 → 运行
mvn clean compile -U（-U参数即--update-snapshots）。 - 方法二：永久启用高频检查 → 在
settings.xml的always
部署快照到远程仓库的完整路径
这需要四个步骤，每一步都至关重要：
第一步：确认 pom.xml 中 distributionManagement 已经配置了快照仓库地址，并且 URL 必须以 /snapshots/ 结尾；
第二步：确保 settings.xml 中对应 server 的 id 与 pom 中的
第三步：执行 mvn deploy → Maven 会自动识别出 -SNAPSHOT，然后将 jar、pom、sha1 校验文件以及 maven-metadata.xml 全部推送到远程快照仓库；
第四步：其他项目执行 mvn compile 时，只要本地缓存过期，就会从那个远程快照仓库拉取最新的构建产物。
快照与 Release 的根本区别
快照仓库允许同一个版本多次覆盖上传，但 Release 仓库严格禁止覆盖——这是 Maven 仓库的硬性规则。一旦你在 pom 中写了 1.0.0（不带 -SNAPSHOT），Nexus 或 Artifactory 就会拒绝第二次部署相同版本号的包。
生产环境绝对禁止依赖 -SNAPSHOT 版本，因为它的内容随时可能变化，而且无法回滚到某个确定的状态。而 Release 版本一旦发布，内容就永久固定，具备可重现性和审计依据。
所以，开发阶段使用 SNAPSHOT，交付前必须切换为 Release 版本——这是上线前的一个强制动作，没有任何商量的余地。
