背景
线上某个项目由于后端 controller 层代码异常, 没有执行到渲染页面模版, 造成前端 Web 页面展示出来是一个空白的页面，俗称白屏。
思考
页面出现白屏, 势必需要从头到尾逐步去排查问题, 找到源头和原因
-
确认页面的 HTTP 请求有没有问题
-
如果是 404 了(我们这次的现象就是 404 白屏), 那需要再往后端方向排查问题
-
如果页面内容返回正常, 那很有可能是前端渲染方面的问题, 那就需要往前端方向去排查
-
-
分析 HTTP 服务器日志, 例如找运维查看 nginx 的访问日志有没有出现异常情况
-
分析 Application 服务器日志, 例如查看 tomcat 的应用日志有没有出现异常情况。 例如这次问题确定是应用层出现异常产生的 404
-
最后找到关键代码, 确定问题, 修复上线
想想排查问题的流程还是比较长, 比较费时的。如果出现错误时, 不是给一个白屏, 让人去猜哪里出现了问题, 排查一圈才能定位问题, 而是给出明确的错误信息, 有一个明确的错误页面就好多了。
设计
错误页面是一个通用的需求, 那么我们在设计的时候就应该考虑设计为一个通用的页面, 能够展示任意的错误信息. 即可以通过参数的形式控制页面的展现。
那么通用错误页面应当具备哪些关键的要素呢? 我们参考各种 404 页面, 抽象之后, 认为关键的三要素如下:
- 错误信息: 面向用户的错误提示
- 错误码: 面向开发者的错误提示
- 引导用户: 出错之后引导用户去"解决"这个问题, 避免走入死胡同, 卡死在这里了, 例如显示回退按钮, 引导用户重试
实现
通过 URL 参数来控制页面的展示和行为：
-
message 错误提示, 默认为: 抱歉，出错了
-
errorCode 错误码, 默认为: 500
-
showPrimaryBtn 是否显示引导按钮, 默认为: true
-
primaryBtnText 引导按钮的文案, 默认为: 返回
-
primaryBtnAction 引导按钮的动作模式: 回退(history-back), 返回到页面(goto)
-
gotoUrl 指定 goto 模式时要返回的页面, 默认为: //daojia.com
效果展示
在线demo
避免安全风险
- 用于控制页面展示的输入参数(例如 message 参数), 因为是可以任意构造的, 要避免出现 XSS 漏洞就必须转义
https://jz-common-cdn.daojia.com/fe-common-page/error-page/index.html?message=%3Ch1%3E%E9%94%99%E8%AF%AF%3C%2Fh1%3E
- 同理 gotoUrl 也是一个可以任意构造的输入参数, 涉及到引导用户跳转, 要避免出现钓鱼风险, 就必须做跳转域名的白名单限制，如
https://jz-common-cdn.daojia.com/fe-common-page/error-page/index.html?primaryBtnAction=goto&gotoUrl=%2F%2F58.com
关注我们
