时间回到半年前，当时接手的项目逐渐进入尾声，最后一步，需要对接一个面单打印的能力。公司早有其他项目组集成了这块的功能，直接拿来接入即可。此时的我也准备从连续多日的紧张开发状态中走出来，以为可以稍稍放松一下。然而，事情并没有这么简单……
友情提示：文章字数不多，不是什么精深的技术博文，只是一点我在工作中如何解决异常的一些思路，希望能够给你带来一些收获和排查异常的经验积累，假如未来的你与我一样也遇到同样的问题，可以通过这篇文章找到最优解。好啦，话不多说，让我们开始吧。
模拟场景
我向 A 同事提出对接的述求，对方表示 ok，然后行云流水地在电脑上打开一个网站： swagger-ui.html。样子如你所见：
需要用到的接口很简单，我回到自己的工位，立马将该链接丢进了浏览器，映入眼帘的……
这些消失的接口我们就称它为：薛定谔的接口。
猜测与尝试
需要说明的是，实际排查该异常时，我的思维过于跳跃，直接导致错过了最正确有效的方法，有时候，我们所谓的直觉其实是在绕圈子……
排查权限 ❌
看到自己的界面与别人的不同，身为前端，我第一时间想到的是 权限，是否需要添加 Authorize，然后界面就不一样了呢？
仔细观察，这些接口并不需要 token、api_Key 等认证信息，因此此路不通。我将这个薛定谔的接口直接丢入了浏览器地址栏，直接反馈 404。换一个浏览器，依旧如此。（PS：当时试到这里，其实我的脑海里曾闪过一个隐隐约约的念头，可惜我没有抓住。）
我不信邪，将该 swagger 文档链接发给了左右两边的同事，有趣的事情发生了，场面变成了这样：
居然有这种事，为何独独我和 B 的 swagger 文档出现了异常？
到这里，因为这个 区域性异常，彻底将我带偏，从而连续出现了下面这些错误的推断。
排查 IP、DNS、供应商网络 ❌
既然界面出现了 区域性异常，我便自然有了接下来的排查思路：
- 先是 IP，我们 5 人的 IP 是连续的，都在同一节点范围内，排除！
- 再是 DNS，其他同事都没有设置任何 DNS 服务器地址，只有我设置了，这已经说明了不是 DNS 的锅，排除！
- 最后是 供应商网络，到这里，我的猜测其实已经放飞自我了，我谷歌：IP，查看宽带，仅仅 5 张桌子，居然移动、电信、联通都有，emmm……，并且，界面正常的 D 和异常的 B 都是使用相同的移动宽带，排除排除！
- 难不成是公司网管在 物理层硬件 上做了什么配置 ？？！
到了这里，我的猜想已经非常离谱了，理智告诉我，不能再放飞自我了。
排查 HTTP cookie ✅
我能肯定一定有人在看到文章标题时，就定位到了这个问题出错的原因。还记得我前文说到我内心那个一闪而过的模糊想法吗？
到了这一步，我终于想起了 HTTP 这位老大哥了，太亲了反而想不起来。
来看下我最终是如何解决这个异常的：我直接从界面正常的同事 D 那拷贝了一份该接口的请求头，丢进了我的 Fiddle 中，之所以选择 Fiddle 而不是 Postman 是因为我还想看点别的，比如是否有一些额外的代理请求在作怪。
没有意外的，在 Fiddle 中使用同事 D 同样的请求头，请求成功了，不再是 404。
我差点欢呼。
我赶忙将浏览器中的请求头参数和 Fiddle 中的进行逐一对比，最终定位到罪魁祸首！意料之外，情理之中。
我：Cookie，果然是你！
Cookie：果然是我。
HTTP 大哥：果然是他。
异常排查到这里就结束了，最终问题出在 Cookie 中的一个自定义属性上：experimentation_subject_id，这似乎是一个实验性质的字段，与 DNS、ISPConfig 有关，会影响我们的 session 和 cookie（若有不对，请在评论区指正，我会修改，谢谢）。
我和同事 B 的浏览器上是没有这个属性的，直接手动加上就正常了。
总结
身为前端，我们的一部分工作就是频繁地与后台交互，HTTP 和 TCP 等协议是我们必须了解的，不仅如此，还要学会配合工具来应用，这是能够有效帮助我们解决许多疑难杂症的利器。比如今天我所遇到的这个文档异常，将它直接丢进接口测试工具中就能立马找到问题出处，不用劳烦别人，能节省很大一部分时间。
那么以后遇到涉及接口的异常，直接丢进接口测试工具进行排查？
我想说：是的，至少这一步优先级很高。
最后
在遇到一个问题时，我们可能无法第一时间把握到正确的解决方向，因为我们的经验还不足够，这再正常不过，也不是什么坏事，大家都是摸着石子一路走过来的，只有走过的路是踏实有底的，倘若你走完还顺带搭了座桥，那自然更棒。
最后，文章产出不易，还望各位小伙伴们支持一波！
本文使用 mdnice 排版
