看到这个标题有人会问了。啊，这个问题不就是 Maven 这个呆逼找不到包了吗？要不镜像里没有，要不lastUpdate文件没清呗。
今天这次还真不是这俩原因，所以我记录下来备忘，也给别人提供一个新思路。
事情的起因是甲方又来找事，大意就是：
哎呀不得了啦！fastjson有重大bug！所有系统必须升级到修复版本！今晚就要！
（PS：这个漏洞起码两个月前就被报出来了）
（PS：傻逼甲方自己内部走流程就左踢右拖，一到厂商这就我不管我不管我现在就要）
虽然蛋疼但是为了这碗饭，升就升呗。修改依赖重打个包呗。事来了。
fastjson 修复这个 bug 在 1.2.83 版本。甲方提供的Maven镜像里，嘿嘿，没有。
为啥要用甲方的镜像？当然是他们要推广自己封装的微服务框架啦。
反映问题得到的结果就是：我们目前只提供到 1.2.56 。项目组自己想招吧。
那加个阿里的镜像吧，这下fastjson是下载了，甲方的框架又找不到了。
Maven这个小暴脾气还不能脚踩两只镜像。结果就是甲方框架和fastjson不可兼得。我搬起砖就没法抱你了属于是。
现在的情况就是。依赖的文件明明都在本地仓库里躺着，Maven就是不愿雨露均沾。
为什么呢？Maven为什么就是不认这份下载好的依赖呢？网上的说法就是，Maven觉得这个文件不对，不是新的。
咋判断的呢？现在目录里的文件有：jar和pom，他俩对应的sha1，maven自己搞的_remote.repositories。
试着把jar和pom以外的文件备份后删掉。结果就，成了，Maven老实打包了。
任务是完成了。但还是没搞清怎么回事。
先把sha1拿回来，发现并无影响。（开始还觉得与什么校验有关，看来并不是用到这里）
再单独把remote拿回来，果然又犯病了。看来问题就在这。
打开_remote.repositories，就一点点内容
#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Wed Jul 27 17:09:03 CST
fastjson-1.2.83.jar>alimaven=
fastjson-1.2.83.pom>alimaven=
刨去注释就两行，仔细一看就是 文件名>镜像id=
咋个原理不知道，但能看出来这里的镜像id是下载文件时使用的镜像：alimaven。而非当前在用的 nexus。
要不我改回去试试？
#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Wed Jul 27 17:09:03 CST
fastjson-1.2.83.jar>nexus=
fastjson-1.2.83.pom>nexus=
然后再让Maven更新，一切就都正常了。
看来Maven是以此文件判断相关依赖是不是从当前镜像下载的，不是就重新下载。
所以要想让Maven老实用本地的文件，把这个删了就完了。
