摘要：而這一次的項目，原本以為開發挺順利的，但是開發完了，才發現自己犯了一個低級而嚴重的錯，這樣的一個失誤，我一直耿耿于懷。但是監聽用戶退出頁面微信瀏覽器上面的那個返回或者關閉按鈕卻死活不行。也容易犯一些低級的錯誤。

前端從事了超過兩年，修復了無數的bug，寫了無數的bug；挖了很多次坑，填了很多次坑；犯了很多次錯，彌補了很多次，學習了很多次。一般而言，對于bug、坑，都是修復完了或者填完了，并且記住為什么會產生bug，為什么有坑，為什么犯錯，怎么解決的，下次怎么避免，就行了，就學習到了。而這一次的項目，原本以為開發挺順利的，但是開發完了，才發現自己犯了一個低級而嚴重的錯，這樣的一個失誤，我一直耿耿于懷。

在3月9號的這一天，公司有個活動，希望用答題活動推廣自己的小程序。結果因為開發時間太緊，小程序在3月5號才提審。在3月8號早上，小程序還沒有審核，在不得已的情況下，只能把答題活動以網頁的形式進行，使用vue開發。由于在3月9號要用到這個答題活動，所以3月8號必須要完成開發，測試，驗收。

開發的過程，都挺順利，只是把小程序的一些代碼，改成vue開發移動端網站的方式，把標簽換了，樣式稍微重寫一下，項目就跑起來了，至于一些交互邏輯，由于不能使用小程序的API，只能另找良方代替，但問題基本不大。

麻煩的一個需求就是：當用戶沒答完題中途退出的時候，要記錄用戶的答題狀態。比如答了哪些題目，哪些題目錯了，哪些題目正確了，拿了多少分等數據。在小程序里面，很輕松可以利用生命周期函數 unload() 進行監聽。當用戶沒答完題退出頁面的時候，把用戶當前的答題數據，傳給后臺，讓后臺進行保存。在用戶下次進入頁面的時候，我可以根據后臺返回的用戶答題狀態，進行信息的展示。如果用戶沒答過題目，就重新開始答題，如果用戶上次退出的時候，沒答完題目，就按照退出時的進度，讓用戶重新答題，如果答完了題目，直接顯示答題結果頁面。

這個需求不難實現，小程序有 onload() 和 unload() 兩個生命周期函數，只是在這兩個函數里面，調兩次接口而已。

但在網頁里面，監聽用戶進入頁面簡單。但是監聽用戶退出頁面（微信瀏覽器上面的那個‘返回’或者‘關閉’按鈕）卻死活不行。網上最多的解決方案是這個，但是不知道是我使用方式有問題還是人品問題，壓根沒用，無論是微信開發者工具，還是安卓或者蘋果真機。

答案來自知乎：微信自帶瀏覽器環境內左上角返回、關閉按鈕事件監控？

pushHistory(); 
window.addEventListener("popstate", function(e) { 
    alert("我監聽到了瀏覽器的返回按鈕事件啦");//根據自己的需求實現自己的功能 
}, false); 
function pushHistory() { 
    var state = { 
        title: "title", 
        url: "#"
    }; 
    window.history.pushState(state, "title", "#"); 
}

根據網上的方案，試了幾個（包括vue的生命周期函數），沒一個可行的。最后無奈之下，只能用一個蠢方法，用戶點擊每一題選項的時候，就把用戶當前的記錄，通過接口發給后臺，讓后臺記錄。這個就是我該文章說的低級嚴重的失誤，想必大家也知道是怎么回事了。

這次的答題活動，一共有三輪，每輪10道題，現場大概有500人答題。本來使用小程序開發，不管用戶是沒答題就讓用戶可以開始答題，答題途中退出就記錄狀態，答完題就顯示結果。在這個過程中，我跟后臺交互的只有兩次：一次是用戶進來的時候獲取用戶答題進度，一次是用戶答完了最后一題，發送用戶成績，讓后臺記錄；或者中途退出，發送用戶答題進度給后臺，讓后臺記錄。

但是后來我在網頁中，由于暫時沒法監聽用戶是否退出，所以選擇了用戶回答完每一題的時候，把數據發給后臺，讓后臺答題進度。這樣請求數就多了N倍。服務器的壓力就大了很多。

由于用戶進來，無論是小程序還是網站，都要請求接口，獲取用戶答題數據，這次不在對比范圍。這樣原本小程序只需要和后臺進行一次握手，但是在網頁中，采用了不合適的方式，和后臺握手次數變成了10次。足足多了9倍。如果是500人，每一輪從原本的500次，變成了5000次，三輪就從原本的1500次，變成了15000次！一般而言，10道題選擇題，是兩分鐘左右的回答時間，就相當于在2分鐘內服務器要響應的次數多了9倍，這個擔子突然重了很多。而已這些請求，基本都有沒什么意義的，因為絕大部分的人，10道題，大概兩分鐘的答題時間里面，不會中途退出，相當于我做了一件沒意義，又消耗服務器性能的事情。

讓我耿耿于懷的原因，我一向對請求數嚴格的控制，雖然現在公司不怎么考慮性能，服務器壓力。但是這會引起我的強迫癥。

由于答題活動，9號要使用，而我是8號晚上洗完澡的時候和同事聊天的時候才想起，所以我沒時間改了，因為改了也是需要時間開發，測試。9號由于同事請假，他的項目也由我負責，也是比較趕的項目，我也沒那么多時間改。只能委屈一下服務器了。

說是這樣說，但是關于其他的給服務器減輕負擔的方案，還是有比較講一下，算是給自己提個醒，也算是給大家提個醒。開發要注意一點：不要急，不要急，不要急。

PS：當時就是看著時間差不多是下午四點半了，然后還有兩個零散功能沒做，又要測試。找了很久的解決方案（監聽微信的‘返回’或者‘關閉按鈕’）都沒下落的情況下，一下急了，腦袋放空，就想了那個方法。

記錄用戶的狀態，這個應該是最好的解決方案了，也應該是最簡單的解決方案。

比如使用cookie記錄用戶的答題進度。在用戶每答一題的時候，就把cookie記錄到的數據，更新一次。這樣只需要在用戶答完了最后一題的時候再把用戶的成績發給后臺就好，至于用戶中途退出也沒有，根據cookie判斷就好，如果cookie有記錄到用戶的數據。就顯示上次用戶退出時候的題目，讓用戶繼續答題。

/**
* @dedependson 點擊選項
* @index 題目索引  number
* @item 當前選項對象 object
*/
chooseDo(index,item){
    /*其他代碼略*/
    let _this=this;
    let _data={
        qid:_this.qid,//答題輪次，如"2"代表第二輪答題
        questions:_this.questions,//已答題目，"1,2,3"這個表示id為1，2，3的題目已經回答了
        totalScore:_this.totalScore//當前得分
    }
    //發送請求，讓后臺記錄用戶答題進度
    this.$http.post(http_url.submit,_data,{emulateJSON:true}).then(res=>{
            
    })
}

然后再到頁面加載的時候

mounted(){
    this.$http.get(http_url.getQuestions,{
        params:{
            qid:this.qid
        }
    }).then(res=>{
        res=res.body;
        //如果請求成功
        if(res.code===0){
            //如果用戶沒答完題 0-沒開始答題 1-沒答完題   2-答完題目
            if(res.datas.status!==2){
                //獲取答題的題目
                this.questionList=res.datas.entryList;
                //如果題目小于10，就是開始答題了，但是沒答完（中途退出的原因）
                if(this.questionList.length<10){
                    //顯示答題頁面，讓用戶答題
                    this.questionListShow=true;
                }
                //否則就是沒答過題目，讓用戶答題
                else{
                    //顯示開始答題頁面（答題首頁，用戶需要點擊開始答題）
                }
            }
            //如果用戶已經答完題，顯示結果頁
            else{
                //代碼略
            }
        }
        else{
            alert(res.msg)
        }
    })
}
       

chooseDo(index,item){
    /*其他代碼略*/
    let _this=this;
    let _data={
        qid:_this.qid,//答題輪次，如"2"代表第二輪答題
        questions:_this.questions,//已答題目，"1,2,3"這個表示id為1，2，3的題目已經回答了
        totalScore:_this.totalScore//當前得分
    }
    //保存cookie一天
    //_this.qid作為答題輪次的標識
    setCookie("answer-qid"+_this.qid,_this.qid,1);
    setCookie("answer-questions"+_this.qid,_this.questions,1);
    setCookie("answer-totalScore"+_this.qid,_this.totalScore,1);
}    

cookie函數參考:ec-do

//設置cookie
setCookie(name, value, iDay) {
    let oDate = new Date();
    oDate.setDate(oDate.getDate() + iDay);
    document.cookie = name + "=" + value + ";expires=" + oDate;
},
//獲取cookie
getCookie(name) {
    let arr = document.cookie.split("; "),arr2;
    for (let i = 0; i < arr.length; i++) {
        arr2 = arr[i].split("=");
        if (arr2[0] == name) {
            return arr2[1];
        }
    }
    return "";
},
//刪除cookie
removeCookie(name) {
    this.setCookie(name, 1, -1);
}, 

然后再到頁面加載的時候，處理方式的改變。

mounted(){
    this.$http.get(http_url.getQuestions,{
        params:{
            qid:this.qid
        }
    }).then(res=>{
        res=res.body;
        //如果請求成功
        if(res.code===0){
            //如果用戶沒答完題 0-沒開始答題 1-沒答完題   2-答完題目
            if(res.datas.status!==2){
                //記錄答題輪次
                this.qid=res.datas.qid; 
                //獲取答題的題目
                this.questionList=res.datas.entryList; 
                //如果用戶中途退出，我們沒有和后臺對接口，后臺無法記錄用戶答題進度，所以這次請求，返回的結果要么是沒開始答題，要么是答完題了。
                //要還原用戶答題記錄，要使用cookie
                //如果存在cookie記錄，那么用戶肯定是至少答過一題，還原用戶答題進度
                let _answerQid=getCookie("answer-qid"+this.qid)
                _answerQuestions=getCookie("answer-qid"+this.qid).split(",");
                //字符串轉整數
                _answerQuestions.map(item=>+item);
                
                if(_answerQid&&_answerQuestions){
                    this.questionList.fifler(item=>{
                        //item.id是題目的id
                        //如果題目的id存在，就過濾掉
                        _answerQuestions.indexOf(item.id)===-1
                    });
                    //顯示答題頁面，讓用戶答題
                    this.questionListShow=true;  
                }
                //否則就是沒答過題目，讓用戶答題
                else{
                    //顯示開始答題頁面（答題首頁，用戶需要點擊開始答題）
                }
            }
            //如果用戶已經答完題，顯示結果頁
            else{
                //代碼略
            }
        }
        else{
            alert(res.msg)
        }
    })
}

代碼上面，可能用了 cookie 會復雜些，但是就多了幾行而已，差不了多少，反倒是減輕了很多請求。

在小程序沒有使用這個方案，就是考慮到用戶退出小程序，可能會清除緩存，雖然這個幾率不大，所以使用生命周期函數進行unload()進行監聽，用戶退出就把用戶答題進度提交給后臺，讓后臺記錄，這樣的情況不會很多，甚至沒有，請求不會很多，所以當時就用了這個方案。沒有使用cookie或者localstore。

注意幾點：

1.無論什么情況，開發都需要一個清醒的頭腦，因為頭腦不清醒，寫的都是bug，那個活動是一個一次性的項目，如果是長期的，我肯定會重構的，因為當時寫的代碼太爛了。也容易犯一些低級的錯誤。

2.不要為了小概率的事件想得太多，給自己，同事，服務器都帶來麻煩，也影響項目進度。這次就是想得太多，結果提測的時間晚了，驗收的時間晚了，自己也犯了錯誤。想太多的后果可能就是撿了芝麻，漏了西瓜，甚至是偷雞不成蝕把米。

這次的的失誤就告一段落了，我也總結了一下，自己為什么會對這次失誤更更于懷。

1.最近一直在看怎么優化代碼，讓代碼更有可讀性，可維護性。卻犯了請求數過多的錯。顧此失彼啊。

2.第二個就是因為這次失誤，導致的后果太嚴重了，直接多了90%的請求。以往失誤導致的后果沒怎么嚴重。

3.以往犯錯的時候，在項目上線之前能夠發現，并且有時候改，這次不一樣，這次是發現了，但是沒時間改了。

4.那些以為不會有，不應該犯的錯。可能就在頭腦不清醒的時候，就會犯這些錯誤，無論什么時候都得留個神，這次也算是我自己提醒自己了。

不過結局是還算是好的，當天因為時間關系，答題活動沒有進行，所以服務器沒有受到考驗。如果當天服務器承受不住壓力，崩了，我也可能要引咎辭職了！

好了，故事就是這樣了，有點日記的感覺，希望大家諒解下。如果文章有什么地方寫錯了，也歡迎指點交流。

--------------------華麗的分割線-------------------

想了解更多，關注關注我的微信公眾號：守候書閣