美乐迪597加载异常排查记录一则

这个问题其实挺常见的，但第一次遇到的时候，还是容易被带偏。
APP 明明是照着流程编译出来的，启动也正常，就是一直卡在加载阶段，有的显示正在初始化资源，有的干脆一直转圈，看起来像是客户端的问题。

一开始我也是顺着客户端方向去看的，后来发现越看越不对劲。最直接的办法，还是先抓一下网络请求，看看它到底卡在什么地方。

抓包之后发现，请求并没有完全停住，而是反复在请求一个文本资源。地址看着也不复杂，就是一个 index.txt。
这个时候基本就能判断，问题大概率不在 APP 本身，而是在资源加载这一层。

我顺手把这个地址直接丢到浏览器里试了一下，结果浏览器直接提示内部服务器错误。

到这里其实就很清楚了，这已经不是客户端能解决的问题了。
既然浏览器都打不开，那只能说明 WEB 这边本身就有问题，APP 只是被动等结果。

接下来就是直接上服务器看站点配置了。
找到对应的 WEB 站点之后，先没急着改东西，只是把 IIS 里能点的地方都过了一遍，想看看有没有明显异常。

后来是在 MIME 类型这里发现了一点不对劲。
点进去之后，IIS 会直接弹错，提示 web.config 里有配置冲突。这种错误平时其实不太容易第一时间注意到，因为站点有时候还能打开，但某些文件就是加载不了。

顺着提示去看 web.config，果然在 staticContent 这一段有问题。

这部分配置看起来很“合理”，各种扩展名都配好了，但问题就在于有些类型在当前环境里是重复或者冲突的。
IIS 对这种情况的容忍度并不高，一旦解析失败，直接就会影响资源访问。

当时的处理方式也很简单，直接把这一整段相关配置清掉，保存文件，然后重新加载站点。

清理完之后，再回到 IIS 里，从界面手动补一个通配的 MIME 类型，让资源以流的方式返回。
这一步做完，再刷新站点，错误提示就不见了。

回头再看 APP，那种一直卡在加载中的情况也就自然消失了。

整个过程下来，其实并不是多复杂的操作，主要是定位思路的问题。
如果一开始就死盯着客户端，很容易在错误的方向上来回折腾。

这类问题以后再遇到，基本第一反应就是先看网络请求，只要浏览器都打不开的地址，就不用再怀疑 APP 逻辑了，直接去 WEB 端找答案会快很多。

写下来也算是给自己留个记录，下次再碰到类似结构，知道从哪一步开始查，不至于再绕一圈。