簡約而不簡單的通用錯誤頁面

背景

線上某個項目因爲後端 controller 層代碼異常, 沒有執行到渲染頁面模版, 形成前端 Web 頁面展現出來是一個空白的頁面,俗稱白屏。html

思考

頁面出現白屏, 勢必須要從頭至尾逐步去排查問題, 找到源頭和緣由前端

  1. 確認頁面的 HTTP 請求有沒有問題nginx

    • 若是是 404 了(咱們此次的現象就是 404 白屏), 那須要再日後端方向排查問題後端

    • 若是頁面內容返回正常, 那頗有多是前端渲染方面的問題, 那就須要往前端方向去排查tomcat

  2. 分析 HTTP 服務器日誌, 例如找運維查看 nginx 的訪問日誌有沒有出現異常狀況安全

  3. 分析 Application 服務器日誌, 例如查看 tomcat 的應用日誌有沒有出現異常狀況。 例如此次問題肯定是應用層出現異常產生的 404bash

  4. 最後找到關鍵代碼, 肯定問題, 修復上線服務器

想一想排查問題的流程仍是比較長, 比較費時的。若是出現錯誤時, 不是給一個白屏, 讓人去猜哪裏出現了問題, 排查一圈才能定位問題, 而是給出明確的錯誤信息, 有一個明確的錯誤頁面就好多了。運維

設計

錯誤頁面是一個通用的需求, 那麼咱們在設計的時候就應該考慮設計爲一個通用的頁面, 可以展現任意的錯誤信息. 便可以經過參數的形式控制頁面的展示。spa

那麼通用錯誤頁面應當具有哪些關鍵的要素呢? 咱們參考各類 404 頁面, 抽象以後, 認爲關鍵的三要素以下:

  1. 錯誤信息: 面向用戶的錯誤提示
  2. 錯誤碼: 面向開發者的錯誤提示
  3. 引導用戶: 出錯以後引導用戶去"解決"這個問題, 避免走入死衚衕, 卡死在這裏了, 例如顯示回退按鈕, 引導用戶重試

實現

經過 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
複製代碼

關注咱們

相關文章
相關標籤/搜索