前言
前组长龙哥研发了friday及friday-cli，friday是类似qiankun的微应用，但是功能和成果和qiankun差距还是很大(相比于single-spa只做了一个js隔离)；friday-cli，见名知意，微应用的脚手架，用来快速搭建微应用的脚手架。但是这两个基建没有在公司推广，因为还不够完善，今天我就来介绍下我碰到的问题，以及解决的思路和解决完问题后的总结。
背景
自从开发微应用以来，总是有一部分人的电脑经常会出现微应用无法热更新的现象，也就是父应用的微应用模块无法热更新。最近我和另外几个同事 老陈 和 老孙 和老蒋 又出现了这个问题，每次只能打包后，使得父应用访问子应用dist文件，访问打包后的微应用。每次微应用写完一点代码必须重新打包(npm run build)，效率特别慢，开发的比较痛苦，而且还找不到原因。但是有些同事的电脑是可以的，热更新正常。
我最近业务开发比较多，今晚终于能抽出几个小时时间，想排查一下这个问题。
过程
初步排查
首先我想到是windows和mac的差异，但是有一些mac和windows本的同事都会有这个问题，而且有的人是突然就不行了，又突然行了。
正常排查
其次，我找来一台没问题的mac和我不能热更新的windows进行对比，发现mac可以正常热更新(子应用代码改变后，通过webosocket通知浏览器，浏览器发起fetch和xhr请求获取更新后的变动内容)，但是我的windows本不可以。我感觉热更新模块出了问题(我们的微应用项目之前使用的webpack，后来换成了内部自研脚手架工具hammer)，可能是换成hammer后，一部分人的热更新出现了问题，但是通过看hammer源码，发现并没有什么问题。
到目前为止，我觉得我的思路是错的，如果是热更新出现问题，不可能时好时坏。
进入正轨
这是我想到前端时候看的friday源码，有一个获取微应用所在地址的步骤，这时候我猜测的到可能是获取的微应用地址不对，因为总是会访问dist文件夹，不会访问写入到内存的微应用文件，这时候我访问微应用根目录的服务(node服务，跟webpack一样的devServer服务)，发现果然，获取的微应用地址不对。
正常mac本的微应用地址是 http://localhost:8001/static/js/app.js ，这个地址是微应用起的服务，我的windows本是 /apps/order/static/js/app.js ,很明显mac访问的是微应用热更新后 编译后文件所处的内存，windows访问的是dist下的磁盘。
那为什么会出现问题呢？我们需要去看微应用根目录的服务，为什么返回的路径不一样，肯定是这个node服务返回的地址出现了问题，我们接着排查。
深入探究
因为微应用根目录的服务的启动是用friday-cli，我们就去看firday-cli源码，直接去找node_modules下的friday-cli，一层层的的找文件，找对应函数，debugger和console.log，大概找到十多层文件，一百来个函数。在console.log的帮助下，锁定了get-dev-app-ports.js这个文件，如下的代码：
const cmd = (0, _utils.isWin)() ? `netstat -ano | grep ${pids.map(pid => '-e ' + pid).join(' ')}` : `lsof -p ${pids.join(',')} -nP | grep LISTEN`;
console.log(cmd,'--->cmd') //netstat -ano | grep -e 31876
const lines = _shelljs.default.exec(cmd, {
silent: true
}).toString().split('\n');
就是在这里，我们可以看到cmd打印出来是
netstat -ano | grep -e 31876
netstat -ano 这个命令我经常使用，查看占用端口号，grep 这个我几乎没见过，这时候我想到可能是cmd、powshell、bash等等命令行工具 可能不一定支持 grep ，果然，尝试了一下cmd、powshell 是会报错的。问题就显而易见了。
结论
子应用根目录的服务，因为无法识别grep这个命令，导致无法检测到根目录下启动的子应用(占用端口的服务)，进而默认返回dist文件夹下的内容。解决这个问题只需要用bash代替cmd及powshell一些命令行工具即可。
总结
1. 在开发项目的时候，尽量使用bash，因为有些脚手架可能不支持特殊的(mac\linux)命令。
2. 看源码的时候大胆一点，学会分析与猜测。
3. 当然，兴趣也是很重要的。