前端不要轻易轮询

  如非必要，尽量不要轻易轮询。盲目地用轮询往往会增加工作量、给服务器造成负担、没有实现实际功能。这里阐述下几种本来需要前端轮询、后面变成后端控制的场景。

  一、后端操作有延迟、比如需要社保苏醒时间等
  执行某种编辑操作之后，前端在成功回调中刷新页面，结果数据不刷新。后端有某些操作是会延迟1~3秒才能真正地生效，这种情况，不要轮询、不要前端去瞎setTimeout,而是要让后端在操作真正完成之前将接口处于挂起（pending状态）。这样子才能将页面刷新的时间缩短至最小。

  二、后端也去轮询查询
  场景：后端去轮询某个接口，最长时间不超过一分钟（其实一般如果请求封装的时候有设置超时时间，可能需要考虑轮询，或者看看能不能将请求的超时时间改成可配置，默认是设置的时间，但是可以针对特定接口进行修改）。如果项目没有设置或者设置的超时时间比后端（后端去轮询一般也有设置超时时间）的要长，那么应当让后端将接口挂起，而不是轮询。

  三、业务需求：实时更新服务截止日期。
  这种轮询需要明确是否有必要，像我们的webui项目的token过期时间就是半小时，这种一般重新登录之后，会自己重新去请求服务是否过期的接口，可以不再轮询。这种情况，如果要轮询，需要尽量减少轮询的时间，比如距离服务过期还剩下一天才开始轮询或者是其他方法