纸上得来终觉浅，绝知此事要躬行。哪怕是平时一个不起眼的小常识，咱们也须要以认真的态度去学习，否则，说不定什么时候就会踩到坑，挫伤到彼此！
前戏
不论文章水不水，前戏都必须做足，否则写不上来啊，O(∩_∩)O 哈哈~
之前公布了《前端 JavaScript 之『防抖』的简略代码实现》这篇文章之后，有一位敌人发了这么一条评论：
我在写代码时有一个习惯：就是对曾经销毁的变量顺手赋一个 null，比方这样的：
据说这样销毁的更彻底哦 o(~▽~)d。
针对下面这位敌人的倡议，我也不确定是不是正确，如同平时也的确很少见到在 cleatTimeout 之后再赋值为 null 的操作。
对于不能确定的问题，我只深信一个准则——实际是测验真谛的唯一标准，既然有了困惑，那就入手验证好了。没错，我就是这么间接，请不要诧异！︿(~︶~)︿
意外
原本认为是很简略的一次验证而已，洒洒水啦！可是，谁想却产生了意外，不信你看：
What?! setTimeout 的返回值是一个数字！！就问你：惊不惊喜意不意外？
好歹做了几年开发了，我竟然不晓得这个事，几乎弱爆了！不过话说回来，谁平时会闲着没事去打印它的返回值啊，咱们用的是它的性能好不好。
为什么会呈现这么个后果呢？咱们来看看 MDN 上怎么说：
返回值
timeoutID是一个正整数，示意定时器的编号。这个值能够传递给clearTimeout()来勾销该定时器。
看来这是常识性问题，只怪我平时没留神啊，看来平时要增强基础知识的储备了！
至于为什么 timer 的值始终在减少，MDN 上是这样解释的：
在同一个对象上（一个 window 或者 worker），
setTimeout()或者setInterval()在后续的调用不会重用同一个定时器编号。然而不同的对象应用独立的编号池。
timer 每次执行的实质是生成了一个新的延时器，属于不同对象，所以编号产生了扭转。
原本还想要再看看 setInterval 的，然而看到这个解释，我就打消了验证的念头，那必然又是一次”惊喜“。
验证
通过了后面这个意外，让我晓得了本人的无知。但意外也是最好的鞭策，即便羞愧，然而结尾所说的验证还是得往下走。
当初咱们晓得了一个真谛：setTimeout 的返回值是一个代表延时器对象惟一身份标识的数字，那么在 clearTimeout() 之后，它的值到底会变成什么呢？请看大屏幕：
咱们看到，在调用 clearTimeout() 办法销毁延时器后，timer 的值并未被清空。
总结
通过下面的验证，咱们能够得出以下论断：
- 延时器办法 setTimeout() 的返回值是一个代表定时器惟一身份标识的编号；
- 这个编号是定时器毕生成就带的，定时器执行过程中，编号不会发生变化；
- 计时器 setInterval 和 延时器 setTimeout 共用一个编号池，且所有编号都不会反复；
- 在调用了定时器销毁办法（clearTimeout 和 clearInterval）后，定时器编号不会被清空。
以上总结实用于所有定时器（计时器和延时器）。
嗯，看来我顺手赋一个 null 的做法还是比拟正当的，毕竟是起到了那么一丝丝的作用的（~︶~）↗。
顺手赋 null 是一个好习惯！(~▽~)~*
顺手赋 null 是一个好习惯！(~▽~)~*
顺手赋 null 是一个好习惯！(~▽~)~*
其实，明天这个验证也证实了另一个情理：咱们平时最漠视的，往往是咱们自认为最相熟的，挫伤了对方而不自知！
你品，你细细品！
~
~
~ 本文完，感激浏览！
学习乏味的常识，结识乏味的敌人，塑造乏味的灵魂！
大家好！我是〖编程三昧〗的作者 隐逸王，我的公众号是『编程三昧』，欢送关注，心愿大家多多指教！
常识与技能并重，内力和外功兼修，实践和实际两手都要抓、两手都要硬！