還在用 SetInterval？定時器翻車了......
前端開發中，有一個 API 幾乎所有同學都用過，那就是：setInterval。
很多同學會使用它完成各種功能，比如：輪播圖、定時任務，甚至有些同學會用它控制動畫等等的。
但是，但是，問題來了。。。
真實場景
1. 跳秒問題
當我們在使用
setInterval做定時任務，頁面切出去，再切回來，可能會出現“跳秒” 的問題。
看一個真實場景。
比如咱們現在要做一個 倒計時 或 定時任務，參考以下代碼：
setInterval(() => {
leftTime--
updateUI(leftTime)
}, 1000)邏輯很簡單：每隔 1 秒執行一次，倒計時減 1。
在實驗環境下測試完全沒問題，但上線后就很容易出事。
比如：用戶在支付頁面等待時，臨時切出去看了條微信消息，等他切回來的時候，倒計時瞬間“咔咔咔”跳了好幾秒。更嚴重的是，還很有可能出現：頁面還顯示“剩余 10 秒”，但后端已經判定超時，導致支付失敗。
為什么會這樣呢？
這是因為 瀏覽器在頁面切到后臺時，會對定時器做“節流”甚至“掛起”處理，Chrome 會把定時器最小間隔限制到 1000ms，甚至直接暫停，等用戶切回來時，所有延遲的回調會一股腦兒執行，造成倒計時猛跳。
于是，用戶看到的時間和真實時間就徹底錯亂了。
2. 動畫卡頓問題
很多同學在寫動畫時，都會直接用 setInterval 來驅動，比如：
setInterval(() => {
box.style.left = box.offsetLeft + 5 + 'px'
}, 16) // 約等于 60 FPS理論上 16ms 一次，剛好能模擬出 60 幀的絲滑效果。
但上線后，用戶體驗卻完全不是這么回事：
一旦瀏覽器線程稍微繁忙（例如頁面里還有圖片加載、腳本計算），定時器就不可能按時觸發，16ms 可能拖成 30ms、50ms，甚至更長。
這就回導致，動畫本來應該流暢平移，但實際看起來就是一頓一頓的，像是在“丟幀”一樣。如果動畫持續時間比較長，抖動感會越來越明顯。
更坑的是，setInterval 的調度是不和瀏覽器的 渲染節奏 對齊的。
換句話說，它根本不知道什么時候瀏覽器會重繪，于是就可能在屏幕還沒準備好的時候強行更新 DOM，結果就是：CPU 忙，動畫抖，用戶體驗一塌糊涂。
這就是為什么在做動畫時，很多大廠前端幾乎不會再用 setInterval，而是推薦 requestAnimationFrame ！這是因為，它能跟隨瀏覽器的刷新節奏來執行，動畫才真正絲滑。
3. 內存溢出與邏輯錯亂
在實際項目里，很多同學用 setInterval 做 輪詢請求 或者 周期任務，但往往忽略了一個細節：清理。
舉個例子：在一個管理后臺里，你需要每隔 5 秒請求一次接口，刷新任務列表：
setInterval(() => {
fetch('/api/sunday/status')
.then(res => res.json())
.then(updateUI)
}, 5000)看起來沒啥問題，但真實業務中很容易出現以下情況：
- 重復觸發： 頁面上有多個入口會初始化這段邏輯，結果一個頁面里開了 3、4 個定時器，都在請求同一個接口。 后端壓力飆升，前端控制臺瘋狂打印日志，CPU 占用直線拉升。
- 忘記清理： 用戶從 A 頁面跳到 B 頁面，A 頁面的定時器還在跑。 當用戶連續操作幾個頁面時，定時器越積越多，最后導致 邏輯錯亂 + 內存暴漲。
- 級聯 Bug： 有一次，開發同學在組件
mounted里寫了setInterval，卻忘了在unmounted里清理。 結果用戶在頁面里反復切換模塊，幾十個定時器同時在跑，接口請求量暴增，頁面直接卡死。
這類問題往往很隱蔽，開發環境下測試不出來，但一旦上線，就會引發性能問題甚至內存泄漏，屬于那種“天坑選手”。
為什么這些問題會發生？
要搞清楚 setInterval 為什么容易翻車，先得明白它背后的運行機制。
1. JS 是單線程的
瀏覽器里的 JavaScript 引擎，是單線程的。這意味著：同一時間只能做一件事。
當主線程正在執行某段耗時操作（比如大數據計算、復雜 DOM 渲染），定時器即使“到點了”，也得乖乖排隊，等前面的任務執行完再說。
結果就是：延遲疊加 → 執行不準。
2. 定時器屬于宏任務
在事件循環（Event Loop）機制里：
setInterval和setTimeout的回調，都會被放進 宏任務隊列；- 宏任務只有在當前調用棧清空之后，才會被執行。
所以，即便你寫了 setInterval(fn, 1000)，并不意味著它會精確地每隔 1000ms 執行。
真實情況更像是：至少 1000ms 后，再加上隊列排隊的時間。一旦頁面繁忙，定時器就會嚴重“拖堂”。
3. 瀏覽器對后臺頁面的“節流”
為了省電、省性能，現代瀏覽器會對不在前臺激活的頁面做限制：
- Chrome 最小間隔強制拉到 1000ms；
- 有時候甚至直接掛起定時器。
這就解釋了為什么頁面切出去再回來時，倒計時會“咔咔咔”跳秒。
4. 定時器堆積效應
setInterval 有一個“坑”，那就是：如果你的回調函數執行時間 大于間隔時間，新的任務依然會不斷加入隊列。
所以，setInterval 最大的問題就在于：它不是一個精準的“時鐘”，而是一個“排隊觸發器”。
在空閑時，它挺準；一旦頁面復雜、線程繁忙、切換后臺，問題就接連出現。
終極解決方案
那么，既然 setInterval 這么“不靠譜”，那我們該怎么辦？
其實，針對不同的場景，有幾種更好的替代方案。
1. 動畫場景 → 用 requestAnimationFrame
動畫的核心問題是：幀率要跟上瀏覽器的刷新節奏。
setInterval(fn, 16)只是“猜”瀏覽器 60Hz，完全沒同步到真正的刷新。- 而
requestAnimationFrame（簡稱 rAF），會在 瀏覽器即將重繪前 執行回調，保證動畫和渲染對齊。
function move() {
box.style.left = box.offsetLeft + 5 + 'px'
requestAnimationFrame(move)
}
requestAnimationFrame(move)2. 倒計時場景 → 基于時間戳校正
定時任務真正關心的不是“回調執行了幾次”，而是 當前時間與目標時間的差值。
所以更靠譜的做法是：用 Date.now() 或 performance.now() 來校正。
const end = Date.now() + 15 * 60 * 1000 // 15分鐘后
const timer = setInterval(() => {
const diff = end - Date.now()
if (diff <= 0) {
clearInterval(timer)
console.log('倒計時結束')
} else {
console.log('剩余秒數：', Math.floor(diff / 1000))
}
}, 1000)這樣無論頁面切到后臺多久，回來后都會 基于真實時間 計算，避免跳秒問題。
3. 高頻定時任務 → 用 Web Worker
如果你有一些對精度要求很高的定時任務（比如心跳包、數據同步），而且不想被主線程阻塞，可以放到 Web Worker 里。
// worker.js
setInterval(() => {
postMessage('ping')
}, 1000)
// main.js
const worker = new Worker('worker.js')
worker.onmessage = (e) => console.log(e.data)因為 Worker 跑在獨立線程里，不受主線程卡頓影響，定時任務更穩定。
4. 清理與管理機制
最后，不管用哪種方案，清理定時器 都是必做項。
Vue/React 組件卸載時，記得 clearInterval / cancelAnimationFrame，在頁面跳轉或模塊切換時，及時銷毀。
否則再好的方案，最后都有可能會出現 內存泄漏 或者 其他的奇怪問題。
