忽然間的思考（一）：setTimeout究竟需不須要執行完進行clearTimeout?你開心就好...

昨天本菜鳥興高采烈地之外包身份去百度進行面試，雖然預料到會被虐的體無完膚，但仍是一被面到腿軟，以致於一二面的技術都問了些什麼問題，哪些感受沒答好都忘記了。回到家靜坐半個小時，全然沒有想起多少來，直到今天早上的靈光乍現。這個系列，隨緣更新，不是那種陳列面試問題和答案的考試複習題，而是主要將本人經歷過的一些以爲值得寫一篇文章的面試問題，以及對他的思考分享出來。

更新：如今忽然想到面試官的意思多是想說爲何沒有寫這個自定義的定時器的清除方法。。。。。。可能就是這樣吧，對，必定是這樣。只有這樣纔會涉及到閉包嘛。。。。

——————————————————————————————————————

首先說下當時的面試原題，是須要用setTImeout實現一個定時器（爛大街的面試題......）。

提筆就寫：

function fn(f, time){
  f&&f();
  setTimeout(()=>{
    fn(f,time);
  },time)
}
fn(()=>{
  console.log(1);
},300)複製代碼

自信滿滿交上答卷，換來面試官的一聲疑問，「你這個有問題呀，你怎麼不清除這個延時器呀，這每次遞歸都生成了一個延時器呀？」看着一臉茫然的我，還補了一句，是否是沒用過clearTimeout.....

當時心裏即懵逼又想解釋，setTimeout執行完了還須要清除？個人世界觀裏clear小夥子的惟一做用就是將延時器的計劃扼殺在萌芽中的。拋出疑問後，面試官回了一句：「要的要的，回去本身百度下（這廣告打得，行雲流水般順暢）。」後來回到家，我查了一下網上對於setTimeout執行完畢後會不會自動銷燬的回答，發現從14年到今天爲止，說啥的都有。介於clearTimeout對不存在的延時器的id，執行完後都不會報錯也不報警，因此我到目前爲止，也站不許哪一派言論是對的。大佬們有查看網頁中存在的定時器的方法經驗的必定要分享下，本鳥在這裏先謝過了。

setTimeout的問題其實能夠分爲兩類，有限次調用和無限次調用（或是遞歸）。對於實際使用的解決方案的話，這裏找到一個對我比較有說服力的說法。

setTimeout每次都是從新生成一個延時器的，因此首先不存在什麼遞歸函數執行環境不會回收而產生閉包的說法，其次恕我實在看不出哪兒會有由於延時器而致使的內存得不到釋放的狀況，有其餘想法的請在下面幫我解釋下......有的同窗說是由於有個timer一直有值得不到釋放，每一次的遞歸函數走完，timer有沒出去撩騷，爲啥得不到釋放？（又不是人......咳咳。。。）因此我暫時站在不用clear的一方。

唉~寫完感受又水了一篇文章，一上午查資料，問大佬總結一下就是，腦子抽了要用延時器實現定時器。。。最後貼兩張圖，看會兒雞條補補腦子去。

兩個都是60ms空邏輯的固定條件