一个页面在呈现给用户之前需要经过静态资源加载、后端接口请求和渲染这三个过程，我们要做的就是在各个过程中防御可能出现的异常情况，保持流畅的用户体验，同时还要应对来自外部的攻击。
防网络
目前主流的研发模式都是前后端分离，拿React举例来说
functionApp(){const[data, setData] = useState(null); useEffect(()=>{ (async() => {constdata =awaitrequest(); setData(data); })(); });if(!data)returnnull;return(
Hello {data.name}
);}复制代码
网络较差数据返回慢，页面不渲染，一直展示空白页，体验很差，一般我们会加个过渡变成这样：
functionApp(){ … if (!data)return; …}复制代码
查看demo：CodeSandbox
这个能解决数据返回之前页面白屏的问题，但是忽略了静态资源加载的时长，这段时间页面还是处于白屏的状态，所以在加载静态资源之前也应该有个过渡效果，试着修改上面的例子：
首页 .loading {
...
}
复制代码
查看demo：CodeSandbox
先加载loading片段，再加载资源，看起来解决了整体的过渡问题，但是大家仔细观察会发现动画播放了一会又重新开始了，破碎感比较严重，原因相信大家也比较清楚，React重新渲染了loading的节点，所以在数据回来前，不应该让React接管页面，试着再次改造：
/* render.js /importReactfrom"react";importReactDOMfrom"react-dom";exportdefaultfunctionrender(Component, props){constrootElement =document.getElementById(“root”); ReactDOM.render(, rootElement);}/ index.js */import render from “./render”;import request from “./request”;import App from “./App”;(async () => { const data = await request(); render(App, { data });})();复制代码
查看demo：CodeSandbox
在页面内容呈现给用户之前，会一直保持loading动画的效果，避免因网络原因造成用户体验的中断。
防接口
静态资源加载完成之后，我们开始和后端进行通信获取页面数据，首先我们需要处理以下几种可能异常的情况。
超时
一个网页从访问到呈现出来，用户能容忍的等待时间大概是35s，在除去静态资源加载的时间大概12s左右，接口请求应该在3s内返回结果。
如果碰到用户网络较差，而我们又没有设置接口超时，页面会一直处于loading的状态，用户得不到有效的反馈会直接离开。所以我们需要设置合理的超时时间，并在触发超时的情况下给予用户反馈。
我们选择使用原生fetch发起请求，很不巧，fetch不支持超时的参数设置，需要我们手动包装：
asyncfunctionrequest(url, options = {}){const{ timeout, …restOptions } = options;constresponse =awaitPromise.race([ fetch(url, restOptions), timeoutFn(timeout), ]);const{ data } =awaitresponse.json();returndata;}functiontimeoutFn(ms =3000){returnnewPromise((resolve, reject) =>{ setTimeout(()=>{ reject(Error(‘timeout’)); }, ms); });}复制代码
然后在超时的情况下进行提示：
async function request(url, options = {}) { const { timeout, …restOptions } = options; try { const response = await Promise.race([ baseRequest(url, restOptions), timeoutFn(timeout), ]); const { data } = await response.json(); return data; } catch (error) { if (error.message === ‘timeout’) { render(() => 请求超时，请重试); } throw error; }}复制代码
超时提示的功能有了，但是用户重试要么自主刷新页面，要么只能退出重进，体验还是不够友好。
理想的情况应该让用户在当前的页面上直接操作重试，不要有页面刷新或者跳出的过程。我们再次对代码进行调整，模拟一个相对完整的例子：
查看demo：CodeSandbox
错误处理
通用错误处理
拿到请求的结果之后，首先我们把网络相关的错误处理掉：
conststatusText = {401:‘请重新登录’,403:‘没有操作权限’,404:‘请求不存在’,500:‘服务器异常’, …};functionrequest(url, options = {}, callback){const{ timeout, …restOptions } = options;try{constresponse =awaitPromise.race([ fetch(url, restOptions), timeoutFn(timeout), ]);const{ status } = response;if(status ===200) {const{ data } =awaitresponse.json(); callback(data);return; } render( PageError, {children: statusText[status] ||‘系统异常，请稍后重试’} ); }catch(error) {if(error.message ===‘timeout’) { render(PageError, {key:Math.random(), onFetch() { request(url, options, callback); },children:‘请求超时，点击重试’}); }throwerror; }}复制代码
业务错误处理
接下来再处理后端正常返回的业务错误，先和后端约定下返回的数据结构：
{success:true/false,data: {// success为true时返回id:‘69887645366’,desc:‘这是产品描述’, },errorCode:‘E123456’,// success为false时返回errorMsg:‘产品id不能为空’,// success为false时返回}复制代码
处理错误：
if(status ===200) {const{ success, data, errorMsg } =awaitresponse.json();if(success) { callback(data);return; } render(PageError, {children: errorMsg });}复制代码
查看demo：CodeSandbox
请求取消
如果大家经常写React SPA的页面，应该碰到过这种错误：
need-to-insert-img
原因是进入组件A发起了请求，快速切换到组件B，组件A被销毁了，等请求回来后调用setState就报错了，看个简单例子：
查看demo：CodeSandbox
解法也很简单，组件unmount的时候取消请求，可惜的是fetch也不支持，改造下：
functionrequest(url, options = {}, callback){constfetchPromise = fetch(url, options) .then(response=>response.json());letabort;constabortPromise =newPromise((resolve, reject) =>{ abort =()=>{ reject(Error(‘abort’)); }; });Promise.race([fetchPromise, abortPromise]) .then(({ data }) =>{ callback(data); }).catch(()=>{ });returnabort;}useEffect(()=>{constabort = request(‘https://cnodejs.org/api/v1/topic/5433d5e4e737cbe96dcef312’, {}, setData);return()=>{ abort(); };});复制代码
查看demo：CodeSandbox
到目前为止，我们基本上解决了接口异常的各种情况，接下来可以进入到业务逻辑的编写当中了。
建议大家在生产环境中选择类似axios的Http请求库，原生fetch能力太弱
防渲染
异常处理
假设有个页面，展示用户余额，大概长这个样子
need-to-insert-img
后端正常返回的数据结构是这样的：
{rest: {amount:“10”} }复制代码
前端渲染逻辑一般是这样的：
余额：{rest.amount}元
复制代码
有一天后端写了个bug，请求成功了，但是没有正常返回rest结构，按照上面的写法，果断报错，Cannot read property ‘amount’ of undefined，页面白屏。
也许有些人的做法是判空：
{rest && rest.amount}元复制代码
这种处理会带来两个问题
很多字段需要判空，大量冗余代码，可读性差
核心数据展示不清晰，给用户带来误导，容易引起客诉
折中的方案是进行一个错误的提示，避免白屏，在React中我们可以通过ErrorBoundary进行统一的处理：
classErrorBoundaryextendsComponent{staticgetDerivedStateFromError() {return{hasError:true}; } state = {hasError:false, }; componentDidCatch(error, info) {// reportError(error, info);} render() {const{ hasError } =this.state;const{ children } =this.props;if(hasError) {return
系统异常，请稍后再试
; }returnchildren; }}functionrender(Component, props){constrootElement =document.getElementById(“root”); ReactDOM.render(, rootElement );}复制代码
查看demo：CodeSandbox
可降级
某天业务提了个需求，在余额页面的底部加个banner广告，新增了广告的获取接口：
functionrequestAd(callback){ callback({ad: {desc:“这是一个广告”} });}复制代码
很不幸，广告接口不稳定，返回的数据经常出问题，按照上面例子的处理方式，会直接走到ErrorBoundary显示异常了，明显是不符合我们预期的。
所以我们需要对非核心业务降级处理：
余额：{rest.amount}元
复制代码
查看demo：CodeSandbox
防重处理
表单提交是一个很常见的场景，一般防重复点击的方式有两种
按钮防重
在按钮上加防重，例如：
functionApp(){const[applying, setApplying] = useState(false);consthandleSubmit =async() => {if(applying)return; setApplying(true);try{awaitrequest(); }catch(error) { setApplying(false); } };return({applying ? ‘提交中…’ : ‘提交’});}复制代码
好处是不影响用户对整体页面的操作，坏处是需要页面管理状态。
全局防重
进行页面的整体遮盖，例如：
functionrequest(url){ Loading.show(‘请求中…’);try{awaitfetch(url); }catch(error) {// show error}finally{ Loading.hide(); }}functionApp(){consthandleSubmit =()=>{ request(); };return(提交);}复制代码
好处是不用页面管理自己的状态，坏处是提示比较重，会阻塞用户其它操作。
防攻击
xss
脚本注入攻击，例如在某个帖子下留言，内容注入一段脚本获取当前登录用户的cookie：
report(document.cookie)复制代码
如果该网站没有做留言内容的输出转义，就会被注入脚本，所有访问该帖子的用户都将是受害者。
如果网站做了输出转义，大家看到就是这样一坨内容：
复制代码目前主流的库或框架默认都帮我们进行了转义输出，像React，如果我们一定要渲染html片段需要使用dangerouslySetInnerHTML。
csrf
跨站脚本伪造，例如在网站www.a.com的某个帖子下面留言，贴了一个钓鱼链接，链接会跳到攻击者开发的页面www.b.com，该页面的内容很简单，自动发起一个帖子回复的请求
复制代码
浏览帖子的用户无意中点到了该链接，就会进行自动回复。常见的防御方式是加token校验，www.a.com通过cookie下发token，进行写操作的时候读取cookie当中的token并放入请求头中进行服务端验证。由于浏览器同源策略的限制，b网站是无法读取a网站的token的。
还有一种方式是添加referer校验，只有白名单中的域名才允许进行写操作。一般是两种方式结合使用，确保网站安全。
csrf是网络请求层面需要防御的，只有框架才会提供完整的功能，例如Angular，一般情况下需要我们自己集成。
小结
上述列举的各种异常情况，在实际当中只占了估计1%不到，但是几乎我们99%的基础代码都是为此而编写的。合格的程序员在编码的过程中首先考虑的就是怎么防御极端异常，只有做好这1%异常处理，才能更好的服务于剩下的99%。
关于我们：
我们是蚂蚁保险体验技术团队，来自蚂蚁金服保险事业群。我们是一个年轻的团队（没有历史技术栈包袱），目前平均年龄92年（去除一个最高分8x年-团队leader，去除一个最低分97年-实习小老弟）。我们支持了阿里集团几乎所有的保险业务。18年我们产出的相互宝轰动保险界，19年我们更有多个重量级项目筹备动员中。现伴随着事业群的高速发展，团队也在迅速扩张，欢迎各位前端高手加入我们~
我们希望你是：技术上基础扎实、某领域深入（Node/互动营销/数据可视化等）；学习上善于沉淀、持续学习；性格上乐观开朗、活泼外向。
https://www.jianshu.com/p/ef188f0288f0
