背景
九月初，炎夏褪去，秋微凉。最近，不知从哪一天开始，早上 5 点钟起床时，天还没亮；晚上不到 7 点，天已黑；四季的车轮，就在人无所察觉中轰隆而过！
言归正传，今天介绍一下 maven 多模块打包过程中蹚过的点，昨天耗费一整天的时间，就只玩了一个 mvn -X clean install 命令，说多了都是学艺不精交的时间学费，值得反思……
功能描述
近期参与的一个产品，技术组合是 maven 多模块 + SpringBoot 后端 + Vue.js 前端。
前一阵儿略玩了一下单模块的打包，昨天被领导安排去部署整个产品，虽说就是一个在父模块根目录下执行 mvn -X clean install 的事情，也遭遇了三个只有原来打包同事【已成为前同事】才知道的问题，总结一下。
不出意外的话，打包其实是很容易的事情，将各个模块 target 目录下的 moduleName.war 上传服务器的 Tomcat 的 webapps 目录下，重启 Tomcat 即可。工程的 build.xml 脚本将所有目标 war 打包到一个 webapps.zip 文件，直接 unzip 该文件，然后上传即可。
虽然也部署过无数次 web 应用，为避免意外，事先备份了服务器上的 webapps 目录。事实证明，小心驶得万年船，程序员的谨慎意识对后来定位问题起到了决定性作用。
问题一：空白页
部署后，访问项目菜单模块时，出现了 SpringBoot 空白页：
问题排查：将这个工程的 war 包还原为备份版本，访问正常，说明直接原因是 mvn 生成的新包有问题。对比 Tomcat 下的两个工程目录，发现空白页面这个工程的 classes 下没有 static 静态资源文件。
理论上，所有前端代码都应该通过 npm build 打包对应的 SpringBoot 后端工程的 static 目录下的，这个空白页产生大概率是访问不到前端页面文件，难道这个工程没有打包前端？
为什么这个工程没有打包前端文件呢？进入它的 pom.xml 中看:
<id>exec-npm-install</id>
<phase>prepare-package</phase>
没有配置这个预处理动作，导致前端文件缺失。除了它，其他所有前后端分离的模块都有，为什么呢？
一再追问下，前同事都被我的问得不耐烦了，真相竟然是这个模块不需要重新打包替换，所以没有配置前端打包命令。
问题二：axios 请求路径错误
解决了第一个问题后，菜单功能正常了，但是 F12 看到控制台一堆 localhost:8080 请求报 404 ,这个问题早有所闻，因为项目多模块之间没法完全独立，所以通过配置文件设置其他模块的后端请求路径 ：
const moduleUrl= {
md1: 'http://localhost:8080/m1',
md2: 'http://localhost:8080/m2',
};
export default moduleUrl;
开发环境，不同的后端工程，内置 Tomcat 端口不同，所以配置 moduleUrl 的时候需要注意端口信息；统一发布到一个 Tomcat 目录后，端口是统一的，但是路径中不能用 localhost ，因为这是前端配置，浏览访问 localhost 的时候，视为本机 IP，所以会请求失败。
解决办法：全局路径配置中，区分开发环境和测试环境，开发环境，直接用相对路径：
const moduleUrl= {
md1: 'http://localhost:8080/m1',
md2: 'http://localhost:8080/m2',
};
if (process.env.NODE_ENV === 'production') {
moduleUrl.md1 = 'm1';
moduleUrl.md2 = 'm2';
}
export default moduleUrl;
问题三：context-path 配置和发布路径不一致问题
最后一个问题，是 SpringBoot 的 servlet:context-path 配置和发布路径不一致导致前端 axios 请求 404 错误。
有一个模块，特立独行，它的模块根路径配置为 / ：
# Tomcat
server:
tomcat:
uri-encoding: UTF-8
max-threads: 1000
min-spare-threads: 30
port: 8084
servlet:
context-path: /
而打包后，该工程为 manager.war ，即部署后，前端应该访问路径是 /manager，但所有的 axios 请求都是相对于根路径的，比如，这个登录请求：
因此前端爆出一堆 404 ，通过对比备份工程和当前工程的网络请求，发现了该问题。
隐藏的这么深，我一个写了半年前端的人，咋可能知道嘛！
启示录
原以为就是放几个 war 包的事情，凭我对 Tomcat 的了解，logs 日志里面没有一个异常，判断部署流程没问题，但是前端页面始终是空白页。鼓足了被讨厌的勇气，追问前同事了十几个问题后，终于搞明白了这个简单部署工作背后要注意的问题。
结论就是，打包真的是个极其考验耐心的工作，耗时又长，稍有问题，就要重来：
- mvn -X clean install 一次，顺利的时候，四十分钟，忘记关 FTP 目录，导致 clean 一半失败了，还要重来；
- 50M 的破网再直连 VPN 上传 六七个 150MB 左右的文件，90Kb/s 的速度，上传完成半个小时到四十分钟，网速还得看运气；
- 重启一次 Tomcat ，5分钟；
- 被领导扣扣追问进度 3 次，电话催问两次，总共20分钟；
- 对比问题包和正常包，以及想到要去对比来定位问题，这个过程一共经过了一小时。
昨天打包这件事，也让我深刻体会到 IT 行业人员变动的时间成本是多么大呀！这些问题原来负责的人都深切经历过的坑点，没有交接给后来人，后者再经历一次排查，虽然成本都是企业的，但当事人可能是自己。
所以，文档很重要，今天公司产品的 doc 目录下已经多了一份打包注意事项。就让这个问题在我手上终结吧，这就是记录的意义！
