setTimeout(〒︿〒) 請原諒我一直以來對你的忽視

這是我參與更文挑戰的第19天，活動詳情查看： 更文挑戰

紙上得來終覺淺，絕知此事要躬行。哪怕是平時一個不起眼的小知識，咱們也須要以認真的態度去學習，不然，說不定何時就會踩到坑，傷害到彼此！

前戲

無論文章水不水，前戲都必須作足，不然寫不下去啊，O(∩_∩)O哈哈~

以前發佈了《前端 JavaScript 之『防抖』的簡單代碼實現》這篇文章以後，有一位朋友發了這麼一條評論：

我在寫代碼時有一個習慣：就是對已經銷燬的變量隨手賦一個 null，好比這樣的：

據說這樣銷燬的更完全哦o(￣▽￣)ｄ。

針對上面這位朋友的建議，我也不肯定是否是正確，好像平時也確實不多見到在 cleatTimeout 以後再賦值爲 null 的操做。

對於不能肯定的問題，我只堅信一個原則——實踐是檢驗真理的惟一標準，既然有了困惑，那就動手驗證好了。沒錯，我就是這麼直接，請不要驚訝！︿(￣︶￣)︿

意外

原本覺得是很簡單的一次驗證而已，灑灑水啦！但是，誰想卻發生了意外，不信你看：

What?! setTimeout 的返回值是一個數字！！就問你：驚不驚喜意不意外？

好歹作了幾年開發了，我竟然不知道這個事，簡直弱爆了！不過話說回來，誰平時會閒着沒事去打印它的返回值啊，咱們用的是它的功能好很差。

爲何會出現這麼個結果呢？咱們來看看 MDN 上怎麼說：

返回值timeoutID是一個正整數，表示定時器的編號。這個值能夠傳遞給clearTimeout()來取消該定時器。

看來這是常識性問題，只怪我平時沒注意啊，看來平時要增強基礎知識的儲備了！

至於爲何 timer 的值一直在增長，MDN 上是這樣解釋的：

在同一個對象上（一個window或者worker），setTimeout()或者setInterval()在後續的調用不會重用同一個定時器編號。可是不一樣的對象使用獨立的編號池。

timer 每次執行的本質是生成了一個新的延時器，屬於不一樣對象，因此編號發生了改變。

原本還想要再看看 setInterval 的，可是看到這個解釋，我就打消了驗證的念頭，那必然又是一次」驚喜「。

驗證

通過了前面這個意外，讓我知道了本身的無知。但意外也是最好的鞭策，即便慚愧，可是開頭所說的驗證仍是得往下走。

如今咱們知道了一個真理：setTimeout 的返回值是一個表明延時器對象惟一身份標識的數字，那麼在 clearTimeout() 以後，它的值到底會變成什麼呢？請看大屏幕：

咱們看到，在調用 clearTimeout() 方法銷燬延時器後，timer 的值並未被清空。

總結

通過上面的驗證，咱們能夠得出如下結論：

1. 延時器方法 setTimeout() 的返回值是一個表明定時器惟一身份標識的編號；
2. 這個編號是定時器一輩子成就帶的，定時器執行過程當中，編號不會發生變化；
3. 計時器 setInterval 和 延時器 setTimeout 共用一個編號池，且全部編號都不會重複；
4. 在調用了定時器銷燬方法（clearTimeout 和 clearInterval）後，定時器編號不會被清空。

以上總結適用於全部定時器（計時器和延時器）。

嗯，看來我隨手賦一個 null 的作法仍是比較合理的，畢竟是起到了那麼一絲絲的做用的（￣︶￣）↗。

隨手賦 null 是一個好習慣！(￣▽￣)~*

隨手賦 null 是一個好習慣！(￣▽￣)~*

隨手賦 null 是一個好習慣！(￣▽￣)~*

其實，今天這個驗證也證明了另外一個道理：咱們平時最忽視的，每每是咱們自覺得最熟悉的，傷害了對方而不自知！

你品，你細細品！

~

~

~ 本文完，感謝閱讀！

學習有趣的知識，結識有趣的朋友，塑造有趣的靈魂！

你們好！我是〖編程三昧〗的做者 隱逸王，個人公衆號是『編程三昧』，歡迎關注，但願你們多多指教！

知識與技能並重，內力和外功兼修，理論和實踐兩手都要抓、兩手都要硬！