今天要说的很简单，没有setTimeout的基本用法，也没有什么特殊用法。
就是想记录一下setTimeout的一个特殊情况，分享给可能也不知道的你们。
setTimeout的基本写法大家都不陌生，如下：
setTimeout(() => {
// 说，你倒计时想干什么
}, millisecond)
其中第二个参数是需要延时执行的毫秒数，大家应该都知道这个时间是不准确的，可以理解为最短延时。至于为什么是不准确，事件循环了解一下。
但是这个最短延时也会骗人，因为它可能会爆炸 😂。
今天跟测一个项目，前端需要通过延时的方式去显示某课程是否开始，未开始展示倒计时界面，倒计时至开始时去掉倒计时界面，拉取主体内容。
但是测试小姐姐反馈说她的课程没有开始，没有显示倒计时，直接就显示主内容。并且没有复现步骤，只此一例。
我表示很诧异，但是也没办法。于是使出十八般武艺，开始在测试环境打断点调试，分析代码逻辑。好半天之后，纳尼，逻辑肯定是对的，我相信我的判断。
然后我突然开始怀疑setTimeout的倒计时时间问题。于是开始查，最后查到了原因，真的是这货的锅，它因为延时时间过长，炸了。
这就是今天的重点：setTimeout 的延时毫秒数是有限制的。millisec 参数是 Int32 类型的，最大值为 2^31 - 1，即 2147483647。一旦超过这个限制，millisec 参数将被视为 0，代码会被立马执行。
setInterval 也一样，毫秒数过大会被当做 0，立即执行。
至于解决方案也比较简单，有以下两种：
- 可以对 setTimeout 进行二次封装，对传入的延时毫秒数做个判断，如果超出限制，给出警告，并使用最大允许延时毫秒进行执行、或者给出警告后不执行。相信我，没有人会等得了这么长时间的。
- 从产品层面解决这个问题，如果等待时间过长，可以用其他的方式来提醒。则不需要倒计时了。
感谢污师葵的评论提问，特此补上解决方案
看完之后，以后如果你也遇到setTimeout失灵的情况，记得想起这茬。
如果你喜欢，欢迎扫码关注我的公众号，我会定期陪读，并分享一些其他的前端知识哟。
