前后端分离 获取客户端ip_前后端分离，如何处理前端的异常？

谢邀，睡前答一波。从用户体验和信息采集角度两个调度回答一下。

准确的说，题主说的服务器连接超时或者服务器端出现异常是服务端的异常，只是在前端表现了出来。最简单的办法，让后端解决，这不是前端可以解决的。

从用户体验角度，必须告诉用户有异常，例如知乎的我自己断开了网络

虽然提示得不够精确，起码用户知道出错了。如果能进一步告知用户大概出了什么错，可能一部分用户能自己查修。异常状态是用户最烦且忍耐程度最低的，足够的提示至少能让用户减少一些迷茫，并给予一些引导(甚至可以甩锅，明明是你网络问题)。

ajax有success回调函数也有error回调函数。promise也有类似的。前后端不分离的情况不多数人喜欢重定向，前后端分离至少还能保持在原来页面，给个提示，要不我编辑了一堆还没保存，给我来个重定向，就算你帮我做了本地保存我也吓个半死。(其实这种处理和前后端分不分离没有太大关系，只是人习惯这样处理。)

不确定的异常，处理异常先找到异常

信息采集方面我比较倾向于服务端采集异常。服务端可以采集到返回响应码，页面URL，资源URL，IP，终端类型，地区，执行的SQL，SQL执行时间，时延......非常多，而一切的异常都会体现在前端。

也有一些异常是服务端处理不友好的，比如前端使用了别人家的CDN资源(资源就不在自己家服务器)，js报错和阻塞(1.js兼容问题。2.突如其来异常的数据导致的死循环、报错、业务逻辑不通)。这类问题自家服务器感知不到，只能从前端采集。

前后端能采集到的数据有交集的，我为什么认为在服务端比较优，很难简单表述，比如我要计算一个web请求开始到结束耗时，可能就已经包含了我上诉的绝大多数东西，又为了保持采集信息的一致性完整性，把一些地区，终端类型等独立拆开采集也会显得很奇怪。

我做的工作基本都是在应用层，告诉用户哪里出错了，为什么错。不怎么涉及采集层(顶多参与采集层数据整理和数据接口的功能设计)，可能有些问题说得不好。不过处理异常还是那句，先找到异常，找到了谷歌基本都能解决。

前端异常多数在开发和测试阶段就解决了，虽然本身前端开发就有各种坑(终端兼容等)，错误更多的来源可能是用户的环境(网络)，服务端(各种情况瞬间爆炸)，没预期到的数据(如某个数据出现突然出现一个空值而不是预期的空数组)。

毕竟前端是，TM一个轮播图都要考虑用户会不会无限快速点下一页，然后突然停止的一种存在。而且基本兼容问题，一般很有趣的用户都会以为是自己机子问题，大坑基本在前端测试阶段就填了，反而服务端的问题一旦出来就是大篓子。

假如你比较喜欢前端监控错误，并找到解决办法，最近一个挺不错的。杨森：把前端监控做到极致​zhuanlan.zhihu.com

当然，可能我上面都是废话，看官可能只是想知道怎么用F12这个按钮。